ISATAP Issues List

Last Updated: February 19, 2005

Document status

Current specification:

draft-ietf-ngtrans-isatap-24.txt

Previous versions:

www.isatap.com/archive

Open Issues List

Issue Number Status Description Submitter
Issue 1 Accepted Are SEND references in Section 8 needed? Juha Wiljakka, Tim Gleeson
Issue 2 Accepted Add text describing use/non-use of LLAO's? Fred Templin; Tim Gleeson
Issue 3 Accepted [SENDPS] statement needed for Security Considerations. ISATAP co-authors
Issue 4 Accepted Temporary/CGA address statement needed for Security Considerations Dave Thaler
Issue 5 Accepted Text on timer settings based on FQDN resolution needs work. Tim Gleeson; Fred Templin
Issue 6 Reject DHCP server/relay deployment on ISATAP routers. Fred Templin
Issue 7 Accepted Various text change suggestions Fred Templin
Issue 8 Accepted "Site Administration" Change Suggestion Fred Templin
Issue 9 Accepted Suggestion to promote RFC2529 to Normative Reference Fred Templin
Issue 10 Reject Add Back Security Considerations from -03.txt Fred Templin
Issue 11 Reject Add Back Security Considerations from -03.txt (part 2) Fred Templin
Issue 12 Accepted Decapsulation Filtering Checks Broken Fred Templin
Issue 13 Accepted Consolidated Security Considerations proposal Fred Templin
Issue 14 Accepted Choosing outer header IPv4 destination address Karen Nielsen
Issue 15 Reject PRLs only maintained on host interfaces Karen Nielsen
Issue 16 Reject Multicast Emulation and DAD Karen Nielsen
Issue 17 Reject Unsolicited RAs on ISATAP interfaces Karen Nielsen
Issue 18 Reject Mechanisms for PRL Population Karen Nielsen
Issue 19 Reject Validity Check for RAs Karen Nielsen
Issue 20 Reject Address Resolution and NUD Karen Nielsen
Issue 21 Reject SENDPS Implications for ISATAP Karen Nielsen
Issue 22 Accepted Neighbor Cache Entries for ISATAP interface Markku Savela
Issue 23 Accepted Type of IPv6 interface in ISATAP interface definition Markku Savela
Issue 24 Reject Splitting the PRL into Ingress and Egress Lists Fred L. Templin

Terminology

When submitting an issue, please fill in the following template:

Description of issue: (short single line description of issue)
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Lengthy description of problem

Requested change:
Proposal

For open issues, the following values are used in the Status Field:

Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
Deferred - The decision reached depends on the outcome of another issue.
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.

Issues can also be given the Reject status, or the version of the document when the accepted fix has appeared.

Issues Discussion

Issue 1: Are SEND references in Section 8 needed?
Submitter: Juha Wiljakka; Tim Gleeson
Submitter email address: juha.wiljakka@nokia.com; tgleeson@cisco.com
Date first submitted: March 10, 2004.
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: 1
Section: 8
Rationale/Explanation of issue:

Similar comments received from both submitters asking whether SEND references in Section 8 are needed?

[FT suggestion]:
Change phrase from "are used" to "are either used or omitted". Sentence in question now reads:

  "Securing mechanisms for neighbor discovery (e.g., [SEND])
   are either used or omitted according to the trust model
   appropriate for the given deployment scenario [SENDPS]."

[Resolution from 3/16 ISATAP authors' discussion]:
Consensus to remove [SEND] statement from Section 8; open new issue
tracker item to add [SENDPS] statement to Security Considerations.

Resolution: Accepted

 

Issue 2: Add text describing use/non-use of LLAO's?
Submitter: Fred Templin; Tim Gleeson
Submitter email address: fred.templin@nokia.com; tgleeson@nokia.com
Date first submitted: March 10, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: 1
Section: 6.3
Rationale/Explanation of issue:

Open issue on whether/not to say more about LLAOs; discussed between submitters.

[Status after 3/16 ISATAP authors' discussion]:
Consensus to remove LLAO specification (i.e., section 6.3) from isatap-21 with one objection.
Fred Templin concern that removing specification would unnecessarily limit future ways forward.
Dave Thaler to draft note seeking clarification on v6ops publication strategies.

[3/17 Update]:
Dave Thaler's proposed note for v6ops sent to co-authors.
Fred Templin e-mail clearing concerns from 3/16 sent to co-authors.

[3/17 Status]:
Fred Templin proposed resolution: remove section 6.3 from isatap-21
and not forward Dave's note to the v6ops list. Pending agreement
from co-authors.

[3/18 Status]:
Proposed resolution approved by co-authors. Issue closed.

Resolution: Accepted

 

Issue 3: [SENDPS] statement needed for Security Considerations
Submitter: ISATAP co-authors
Submitter email address: fred.templin@nokia.com, tgleeson@cisco.com, mohitt@microsoft.com, dthaler@microsoft.com
Date first submitted: March 16, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 10
Rationale/Explanation of issue:

Agreed during 3/16 ISATAP authors' discussion that clarifying note regarding
IPv6 ND trust models and threats required for ISATAP security consideration.

[Proposed text as of 3/16]:

  "The threats associated with IPv6 ND are described in [SENDPS].
   Since an ISATAP link spans an entire IPv4 site, mitigating
   threats by restricting access to a link necessarily entails
   restricting access to the site."

[3/17 Status]:
Pending agreement/change suggestions from co-authors.

[3/18 Status]:
Fred Templin proposes changing  first sentence to:

  "Since an ISATAP link spans an entire IPv4 site, mitigating
   IPv6 ND threats for ISATAP necessarily entails restricting
   access to the site."

[3/19 Status]:
Tim Gleeson sends alternate proposal for first sentence (approved by Fred Templin):

   "Since an ISATAP link spans an entire IPv4 site,
    restricting access to the link (to mitigate threats)
    is achieved by restricting access to the site."

[3/23 Status]:
Mohit Talwar approves proposed text.

[3/29 Status]:
Dave Thaler proposes: "can be" instead of: "is acheived". Proposed

paragraph now reads:

   "The threats associated with IPv6 ND are described in [SENDPS].
    Since an ISATAP link spans an entire IPv4 site, restricting access
    to the link (to mitigate threats) can be achieved by restricting access
    to the site."

Resolution: Accepted

 

Issue 4: Temporary/CGA address statement needed for Security Considerations
Submitter: Dave Thaler
Submitter email address: dthaler@microsoft.com
Date first submitted: March 16, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 10
Rationale/Explanation of issue:

[Proposed text after 3/16 ISATAP authors' discussion]:

  "The use of temporary addresses [RFCxxx] and CGAs [xxx]
   on ISATAP interfaces is outside the scope of this
   specification."

[3/17 Status]:
Pending agreement/change suggestions from co-authors.

[3/23 Status]:
Mohit Talwar approves proposed text.

[3/24 Update]:
Also with new proposed text, second validity check for decapsulation
to be removed as per 3/16 authors' confcall agreement. Validity check
to be removed is:

  "the IPv6 source address is the address of a neighbor on the
   ISATAP interface, or:"

[3/29 Update]:

Both proposed resolutions accepted during ISATAP authors' confcall.

Resolution: Accepted

 

Issue 5: Text on timer settings based on FQDN resolution needs work
Submitter: Tim Gleeson, Fred Templin
Submitter email address: tgleeson@cisco.com, fred.templin@nokia.com
Date first submitted: March 16, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 8.3.2
Rationale/Explanation of issue:

Section 8.3.2, second paragraph, second sentence - text on timer settings based on TTLs from FQDN resolution needs work.

[Proposed text as of 3/16 after e-mail iterations between Tim Gleeson; Fred Templin]:

  "When a FQDN is used, and when it is resolved via a service
   that includes a Time-to-Live (TTL) with the IPv4 addresses
   returned (e.g., DNS 'A' resource records [STD13]), the timer
   is set to the minimum of PrlRefreshInterval and the minimum
  TTL returned."

[3/17 Update]:
Mohit Talwar suggests changing: "a FQDN" to "an FQDN".
Dave Thaler suggests making TTL-based timer setting a SHOULD.
Fred Templin acknowledges suggested changes; proposes:

  "When an FQDN is used, and when it is resolved via a service
   that includes TTLs with the IPv4 addresses returned (e.g.,
   DNS 'A' resource records [STD13]), the timer SHOULD be set
   to the minimum of PrlRefreshInterval and the minimum TTL
   returned."

[3/17 Status]:
Pending agreement/change suggestions from co-authors.

[3/18 Status]:
Proposed resolution agreed by co-authors. Issue closed.

Resolution: Accepted

 

Issue 6: DHCP server/relay deployment on ISATAP routers
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 22, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

[3/22 Initial Submission]:
Older versions of the spec (e.g. isatap-16.txt) included specific guidelines for
deployment of the DHCPv6 server/relay function co-resident with ISATAP
routers, but this is no longer present in -21. Text from the -16 document was:

  "When the site uses DHCPv6 [RFC3315] as the stateful address autoconfiguration
    mechanism, the server/relay function MUST be deployed equally on each router
    is a member of the PRL."

Proposed resolution is to add text such as the above back to isatap-21.txt.
Also to add reference to [RFC3633] to pick up prefix delegation. (Q: do
we also need to say something about receiving DHCPv6 multicast addresses
in section 6.3? These are not covered under a "node's required multicast addresses.")

[3/24 Update]:
Follow-up discussion between Tim Gleeson; Fred Templin. Tim not sure anything
should be said about DHCPv6; notes that DHCPv6 messages are sent to the
"All_DHCP*" multicast address and not unicast. Fred Templin agreed with
Tim's point; suggested that no new text about multicast mappings be added
but proposed the following sentence be added to "Site Administration Considerations":

  "The DHCPv6 [RFC3315] server/relay function MUST be deployed
   on each node that configures an ISATAP router interface
   advertised in the site's PRL."

[3/25 Update]:
Tim Gleeson suggests saying nothing about DHCPv6 in "Site Administration
Considerations"; Fred Templin undecided, but leaning toward Tim's suggestion.

[3/29 Update]:

Agreement from all co-authors to avoid mention of DHCPv6 in ISATAP spec.

Resolution: Reject

 

Issue7: Various text changes
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 24, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S/1/2
Section: 
Rationale/Explanation of issue:

[3/24 Initial Submission]:
Several text change suggestions (with different severity levels) from Fred Templin:

MUST change:
************
1) Under "Normative References", the reference for RFC 3513 is incorrect
and needs to be changed to appear as follows:

+ [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
+ (IPv6) Addressing Architecture", RFC 3513, April 2003.

2) Under "7.2 Decapsulation", we don't currently say what to do when there
is no matching ISATAP interface to receive the packet. Propose changing:

- If an ISATAP interface that configures a matching locator is found,
- the decapsulator MUST verify that the paccket's IPv4 source address is
- correct for the encapsulated IPv6 source address. The IPv4 source
- address is correct if:

to:

+ If an ISATAP interface that configures a matching locator is not
+ found, the packet is silently dropped. Otherwise, the decapsulator
+ MUST verify that the packet's IPv4 source address is correct for the
+ encapsulated IPv6 source address. The IPv4 source address is correct if:

 

SHOULD Change:
**************
3) Under "Terminology", the definition for "ISATAP interface" seems vague. Suggest changing:

- ISATAP interface:
- an ISATAP node's point-to-multipoint IPv66 interface used for
- automatic tunneling; also provides a conttrol/forward plane
- nexus for its associated addresses.

to:

+ ISATAP interface:
+ an ISATAP node's point-to-multipoint IPv6 interface used for
+ automatic tunneling of IPv6 packets in IPv4.

4) Under "1. Introduction", first sentence of last paragraph, we no longer have any text
that describes the conceptual model; suggest dropping the phrase "conceptual model and".

5) Under: "8.2 Router and Prefix Discovery - Router Specification", incorrect use of
"Advertisements" (plural) in first sentence; should be "Advertisement" (singular).

6) Under: "8.1 Conceptual Model of A Host", first sentence of Potential Router List is weak
and gives unnecessary forward reference to text that appears just a few sentences later.
Suggest: s/the mechanisms specified in section 8.3/router and prefix discovery

 

MAY change:
***********
7) Suboptimal wording in section 8.3.4, paragraph beginning: "When periodic events".
Propose following changes:

a) Change:

- When periodic events are scheduled, the node SHOULD set TIMER(i) such
- that the next Router Solicitation event wwill refresh remaining

To:

+ When periodic Router Solicitation events are scheduled, the node
+ SHOULD set TIMER(i) such that the next event will refresh remaining

b) Change:

- routers. While the node continues to schedule periodic events for
- PRL(i), and while PRL(i) continues to actt as a router, the node
- resets TIMER(i) after each expiration eveent as described above.

To:

+ routers. While the node continues to schedule periodic Router
+ Solicitation events for PRL(i), and while PRL(i) continues to act as
+ a router, the node resets TIMER(i) after each expiration event as
+ described above.

 

[3/25 Update]:
Fred Templin proposes rejecting item #2 under "MUST change" above
(reasons given in e-mail).

[3/25 Update]:
Fred Templin proposes additional change suggestion for the "MAY change" category:

8) In Section 6.1, the text is cumbersome and does no align with
the text found in the normative reference as well as it could.
Suggest the following changes:

Change:
- ([RFC3513], section 2.5.1 and appendix A)). They are formed by concatenating
- the 24-bit IANA OUI (00-00-5E), the 8-bitt hexadecimal value 0xFE, and a
- 32-bit IPv4 address in network byte orderr as follows (where the 'm' bits
- represent the concatenated IPv4 address)::

To:
+ ([RFC3513], section 2.5.1 and appendix A) by concatenating the 24-bit
+ IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 32-bit
+ IPv4 address in network byte order as follows:

Change:
- When the IPv4 address is known to be globbally unique, the 'u' bit is set
- to 1; otherwise, the 'u' bit is set to 0 ([RFC3513], section 2.5.1).

To:
+ When the IPv4 address is known to be globally unique, the "u"
+ (universal/local) bit is set to 1; otherwise, the "u" bit is set
+ to 0. "g" is the individual/group bit, and "m" are the bits of
+ the IPv4 address.

[3/29 Update]:
Agreement on proposed resolutions for sub-issues 1) through 8) received from
all co-authors. Issue closed.

Resolution: Accepted

 

Issue 8: "Site Administration" Change Suggestion
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 26, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

[3/26 Initial Submission]:
"Site Administration Considerations" change suggestion.

Under "Site Administration Considerations", we currently have text that unnecessarily
presumes DNS 'A' resource records. This text should have been changed in the same
manner as the change suggestion accepted for FQDN resolution in issue #5.

Suggested resolution:

a) Change the second sentence in section 9. to read: "The PRL is normally maintained as
a FQDN for the ISATAP service in the site's name service, but it may also be administered
by some other means (see: section 8.3.2)."

b) Change the final sentence in section 9. to read: "When the site's name service includes
TTLs with the IPv4 addresses returned, site administrators SHOULD configure the TTLs
with conservative values to minimize control traffic."

[3/29 Update]:
New proposed resolution after receiving comments from Mohit; Tim:

a) "The PRL is commonly maintained as a FQDN for the ISATAP service
in the site's name service (see: section 8.3.2)."

[3/29 Update]:
Dave suggests paragraph restructure:

Site Administrators mantain a Potential Router List (PRL) of IPv4

addresses representing ISATAP router interfaces.

 

The PRL is commonly maintained as a FQDN for the ISATAP service
in the site's name service (see: section 8.3.2). There are no mandatory
rules for the selection of the FQDN, but site administrators are encouraged
to use the convention "isatap.domainname" (e.g., "isatap.example.com").

When the site's name service includes TTLs with the IPv4 addresses
returned, site administrators SHOULD configure the TTLs
with conservative values to minimize control traffic.

Resolution: Accepted

 

Issue 9: Suggestion to promote RFC2529 to Normative Reference
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 26, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

[3/26 Initial Submission]:
The Security Considerations section in older versions of the spec
cited [RFC2529] as normative text, but the reference has somehow
drifted into the informative category in isatap-21. Suggest bringing
this back to normative, since the RFC 2529 Security Considerations
section tells how site administrators should implement site security
and filtering in a way that applies identically for ISATAP.

Suggested resolution is to promote [RFC2529] reference to Normative,
and strengthen the first sentence in Security Considerations to read:
"The Security Considerations in the normative references are
taken as normative considerations for ISATAP."

[3/29 Update]:

Proposal to promote RFC 2529 to normative not supported. Alternate proposed

resolution was to add 1st paragraph of ([RFC2529], Security Considerations)

to Security Considerations for ISATAP as follows:

 

  "Implementors should be aware that, in addition to posssible attacks against

   IPv6, security attacks against IPv4 must also be considered. Use of IP security

   at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons.

   For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant

   except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then

   authentication of IPv4 will add little. Conversely, IPv4 security will not protect

   IPv6 traffic once it leaves the ISATAP domain. Therefore, implementing IPv6

   security is required even if IPv4 security is available."

 

[3/29 Update]:

Proposed alternate resolution accepted.

 

Resolution: Accepted

 

Issue 10: Add Back Security Considerations from -03.txt
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 26, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

Important passages that appeared in Security Considerations in the
'isatap-03.txt' draft are missing friom the '-21.txt' draft and should
be added back. Suggest adding back the 3rd and 4th paragraphs of Security
Considerations that appeared in the -03.txt draft (with updated section
numbers and citations). See:

 http://www.geocities.com/osprey67/isatap/isatap-03.txt

[3/29 Update]:

Fred Templin to draft "consolidated security considerations rewirte" that

would obviate the above proposed resolution; send to co-authors for comment.

 

[4/05 Update]:

Tim Gleeson, Fred Templin, Dave Thaler agree that there is no need

to bring back the text proposed from the -03.txt draft.

Resolution: Reject

 

Issue 11: Add Back Security Considerations from -03.txt (part 2)
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 26, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

Paragraph 5 of 'isatap-03.txt' had better text for expalining trust
basis than currently appears in '-21.txt. Suggest removing the
first sentence of the final paragraph of S.C. in '-21.txt', and
replacing it with the 5th paragraph of S.C. from '-03.txt' (MINUS
the final sentence of that paragraph, PLUS some minor wording
changes). Suggested text for '-21.txt' is:

"([RFC2461], section 6.1.2) implies that nodes accept Router
Advertisements received from on-link routers, as indicated by a
value of 255 in the IPv6 'hop-limit' field. Since this field is
not decremented when ip-protocol-41 packets traverse multiple
IPv4 hops, a different trust model is required for ISATAP. In
particular, ONLY those Router Advertisements received from a
member of the Potential Routers List are accepted (see: section
8.3.3). This trust model is predicated on the IPv4 source address
filtering and ip-protocol-41 filtering described above, and on
administrators ensuring that the Potential Router List for the
site is well maintained (see: section 9)."

[3/29 Update]:

Fred Templin to draft "consolidated security considerations rewirte" that

would obviate the above proposed resolution; send to co-authors for comment.

 

[4/05 Update]:

Tim Gleeson, Fred Templin, Dave Thaler agree that there is no need

to bring back the text proposed from the -03.txt draft.

Resolution: Rejected

 

Issue 12: Decapsulation Filtering Checks Broken
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: March 31, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

 

Problem Statement:

******************

The Decapsulation filtering checks in section 7.2 are incorrect

due to both a faulty definition for the term "ISATAP address",

and broken text in section 7.2.

 

Proposed Resolution:

********************

1) In "Terminology", change the definition of "ISATAP address" to:

 

"ISATAP address:

an IPv6 unicast address with a prefix that matches an ISATAP

interface's on-link prefix, and an ISATAP interface identifier."

 

2) Under Section 8.1: s/Potential Router List/Potential Router List (PRL)/

 

3) In section 7.2, change the text beginning at the second paragraph

to the end-of-section to the following:

 

"If an ISATAP interface that configures a matching locator is found,

the decapsulator MUST employ the following algorithm to determine

whether the packet's IPv4 source address is correct for the

encapsulated IPv6 source address:

 

    if IPv6 source address is an ISATAP address

        if IPv6 source address embeds IPv4 source address

            IPv4 source address is correct

        else

            IPv4 source address is incorrect

        endif

    else

        if IPv4 source address in PRL (see: section 8.1)

            IPv4 source address is correct

        else

            IPv4 source address is incorrect

        endif

    endif

 

Packets for which the IPv4 source address is incorrect are processed

as specified for configured tunnels in ([MECH], section 3.6)."

 

[3/31 Update]:

Fred Templin proposes alternate text for Proposed Resolution, item 3):

 

"If an ISATAP interface that configures a matching locator is found,

the decapsulator MUST verify that the packet's IPv4 source address is

correct for the encapsulated IPv6 source address. For packets with an

ISATAP IPv6 source address, the IPv4 source address is correct if it

matches the IPv4 address embedded in the ISATAP interface identifier.

For all other packets, the IPv4 source address is correct if it is a

member of the Potential Router List (see: section 8.1).

 

Packets for which the IPv4 source address is incorrect are processed

as specified for configured tunnels in ([MECH], section 3.6)"

 

[4/1 Update]:

Tim Glesson writes that the checks don't seem to work because of not

being able to tell whether the ISATAP address is from *this* ISATAP

network or *some other* ISATAP network. Fred Templin replies that

disambiguating the "ISATAP address" definition should fix this.

 

[4/1 Update]:

Fred Templin proposes new definition for "ISATAP address" (to replace

the proposal given in 1) above):

 

    "ISATAP address:

        an IPv6 unicast address that matches an on-link prefix on

        an ISATAP interface of the node, and includes an ISATAP

        interface identifier."

 

[4/1 Update]:

Fred Templin suggests questions need to be answered regarding the

text for decapsulation checks:

 

1) If we receive a packet on an ISATAP interface with a link-local

ISATAP source address, and its embedded IPv4 address does not match

the IPv4 source address, BUT the IPv4 source address is a member of

the Potential Router List, should we drop the packet or hand it

up the stack?

2) Same question for non-link-local ISATAP source addresses.

 

Essentially, these questions are asking: "If an ISATAP IPv6 source

address is failed by the first test (embedded IPv4 matches the IPv4

source), do we drop the packet immediately, or give the packet a

second-chance via the second test (IPv4 source is a potential router)?"

 

Also, is the answer to this question the *same* for link-local

and non-link-local source addresses, or possibly different?

 

[4/2 Update]:

Tim Gleeson comments that ISATAP addresses failed by the first

test must be given a second chance via the second test. Fred Templin

agrees. New proposed resolution:

 

  1) In Terminology, change definition of "ISATAP address" to:

 

    "ISATAP address:

        an IPv6 unicast address that matches an on-link prefix on

        an ISATAP interface of the node, and includes an ISATAP

        interface identifier."

 

  2)  Under Section 8.1: s/Potential Router List/Potential Router List (PRL)/

 

  3) Leave current decapsulation checks unchanged (i.e., reject the earlier

     change suggestions proposed by Fred).

 

[4/5 Update]:

Closer review of Tim Gleeson's 4/2/04 message shows some material for

further discussion before deciding to leave current decapsulation checks

alone (see "4/2 Update"). To be discussed among all authors during

4/5/04 conference call.

 

Fred Templin wrote:

> > 1) If we receive a packet on an ISATAP interface with a

> > link-local ISATAP source address, and its embedded IPv4

> > address does not match the IPv4 source address, BUT the IPv4

> > source address is a member of the Potential Router List,

> > should we drop the packet or hand it up the stack?

 

Tim Gleeson wrote:

> Can link-local packets be redirected? I think the answer is

> YES, but would

> like confirmation. (addr-arch says "routers must not forward

> any packets

> with link-local source or destination addresses to OTHER

> links", my emphasis

> on OTHER.) If so...

>

> The answer is, DON'T DROP. It might be a redirected link

> local carrying the

> address of the original source in the IPv6 source, but the

> address of the

> router doing the redirection in the IPv4 source.

 

[4/5 Update]:

Tim Gleeson, Fred Templin, Dave Thaler agree to most recent proposal:

 

  1) In Terminology, change definition of "ISATAP address" to:

 

    "ISATAP address:

        an IPv6 unicast address that matches an on-link prefix on

        an ISATAP interface of the node, and includes an ISATAP

        interface identifier."

 

  2)  Under Section 8.1: s/Potential Router List/Potential Router List (PRL)/

 

  3) Leave current decapsulation checks unchanged (i.e., reject the earlier

     change suggestions proposed by Fred).

 

Resolution: Accepted

 

Issue 13: Consolidated Security Considerations section needed
Submitter: Fred Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: April 1, 2004
Reference:
Document: isatap-pre21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

From issues 3, 4, 9, 10, and 11 (discussed during 3/29/04 ISATAP authors' conference call)

a new Security Considerations section is needed to consolidate the changes. Closure of

this issue will automatically close issues 3, 4, 9, 10 and 11 also. Proposed text for

consolidated Security Considerations section is:

 

10. Security considerations

Implementors should be aware that, in addition to possible attacks

against IPv6, security attacks against IPv4 must also be considered.

Use of IP security at both IPv4 and IPv6 levels should nevertheless

be avoided, for efficiency reasons. For example, if IPv6 is running

encrypted, encryption of IPv4 would be redundant except if traffic

analysis is felt to be a threat. If IPv6 is running authenticated,

then authentication of IPv4 will add little. Conversely, IPv4

security will not protect IPv6 traffic once it leaves the ISATAP

domain. Therefore, implementing IPv6 security is required even if

IPv4 security is available.

 

The threats associated with IPv6 ND are described in [SENDPS]. Since

an ISATAP link spans an entire IPv4 site, restricting access to the

link (to mitigate threats) can be achieved by restricting access to

the site. As such, site border routers SHOULD implement IPv4 ingress

filtering and ip-protocol-41 filtering to prevent IPv6 source address

spoofing. Site border routers SHOULD also install a reject route for

the IPv6 prefix FC00::/7 [UNIQUE] so that packets with local IPv6

destination addresses will not be forwarded outside of the site via a

default route.

 

The Potential Router List (PRL) provides a trust basis for Router

Advertisement messages received on ISATAP interfaces (see: section 8).

This trust basis is predicated on restricting access to the link as

described above, and on site administrators ensuring that lists of

IPv4 addresses representing advertising ISATAP interfaces of PRL

members are well maintained (see: section 9).

 

The use of temporary addresses [RFC3041] and CGAs [CGA] on ISATAP

interfaces is outside the scope of this specification.

 

[4/5 Update]:

Second and third paragraphs updated based on Tim Gleeson,

Dave Thaler; Fred Templin discussion:

 

10. Security considerations

Implementers should be aware that, in addition to possible attacks

against IPv6, security attacks against IPv4 must also be considered.

Use of IP security at both IPv4 and IPv6 levels should nevertheless

be avoided, for efficiency reasons. For example, if IPv6 is running

encrypted, encryption of IPv4 would be redundant except if traffic

analysis is felt to be a threat. If IPv6 is running authenticated,

then authentication of IPv4 will add little. Conversely, IPv4

security will not protect IPv6 traffic once it leaves the ISATAP

domain. Therefore, implementing IPv6 security is required even if

IPv4 security is available.

 

The threats associated with IPv6 Neighbor Discovery are

described in [SENDPS].  

 

There is a possible spoofing attack in which spurious ip-protocol-41

packets are injected into an ISATAP link from outside. Since an

ISATAP link spans an entire IPv4 site, restricting access to the link

can be achieved by restricting access to the site, i.e., by having site

border routers implement IPv4 ingress filtering and ip-protocol-41

filtering.

 

Another possible spoofing attack involves spurious ip-protocol-41

packets injected from within an ISATAP link by a node pretending

to be a router. The Potential Router List (PRL) provides a list of IPv4

addresses representing ISATAP interfaces of routers that hosts use

in filtering decisions. Site administrators should ensure that the PRL

is kept up to date, and that the resolution mechanism (see: section 9)

cannot be subverted.

 

The use of temporary addresses [RFC3041] and Cryptographically

Generated Addresses [CGA] on ISATAP interfaces is outside the

scope of this specification.

 

Resolution: Accepted

 

 

Issue 14: Choosing outer header IPv4 destination address
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:

 

Section 7:

 

The draft refers to [mech] for the basic tunneling

mech including outer IP header construction, but in principle

the Isatap draft doesn't say anything about

how the outer header IPv4 destination address is chosen.

Shouldn't there be a section about encapsulation like

in the early Isatap drafts, e.g v12,

specifying something like:

 

Encapsulation (from section 6.2 of v12)

 

The specifications in [mech] section 3 are used.

Additionally, the IPv6 next-hop address for packets encapsulated on

an ISATAP link MUST be an ISATAP address; other packets are discarded

and an ICMPv6 destination unreachable indication with code 3 (Address

Unreachable) is returned to the source.

 

[4/26/04 Update (from Fred Templin)]:

The above text first appeared in the -03 version of the spec under

an obsoleted section called: "Sending Rules". 

The IPv4 address of the tunnel endpoint is determined from

the Isatap interface identifier of the next-hop address.

 

[4/26/04 Update (from Fred Templin)]:

The current version of the spec now has sections called "Automatic Tunneling"

and "Neighbor Discovery" that mirror the structure of ([MECH], section 3) and

[RFC2461], respectively. Proposal is to add two new subsections under

"Automatic Tunneling" as follows:

 

"7.2  Encapsulation

 

  ISATAP interfaces encapsulate IPv6 packets for which the next-hop

  address is an ISATAP address.

 

  7.3  IPv4 Header Construction

 

  ISATAP interfaces use static address resolution (see: section 8.4) on the

  next-hop address to determine the IPv4 address of the tunnel endpoint."

 

[4/27/04 Update (from authors' conference call)]:

Upon further consideration, we are proposing no change to the draft.

As for any other interface type, the link layer address is taken from

the result of address resolution. For ISATAP, address resolution is

specified in section 8.4.

 

[5/05/04 Update (from Karen Nielsen)]:

OK - though

 

"4/27/04 Update (from authors' conference call)]:

Upon further consideration, we are proposing no change to the draft.

As for any other interface type, the link layer address is taken from

the result of address resolution. For ISATAP, address resolution is

specified in section 8.4."

 

Here link-layer address refer to what in [MECH], section 3,

is called IPv4 address of tunnel endpoint. [MECH] do not refer to the tunnel endpoint

address as the link layer address of the IP next hop but do explicitly say that the tunnel

endpoint address is something that is configured and stored on each individual tunnel interface.

 

[5/10/04 Update (from Fred Templin)]:

A new section 6 subsection on "Address Mapping -- Unicast/Anycast" could

be added, and the current section 8.4 (first paragraph) could be shortened.

Proposed text follows:

 

+ 6.x Address Mapping -- Unicast/Anycast

+ For unicast/anycast packets sent on ISATAP interfaces, the next-hop
+ address ([RFC2461], section 5.2) MUST be an ISATAP address.
+
+ ISATAP addresses are mapped to a link-layer address by a static
+ computation, i.e, the last four octets are treated as an IPv4 address
+ to be used as the destination address in the encapsulating IPv4

+ header (see section 7).

...

+ 8.4 Address Resolution
+
+ The specification in ([RFC2461], section 7.2) is used.

+

+ Hosts SHOULD perform an initial reachability confirmation by sending
+ Neighbor Solicitation message(s) and receiving a Neighbor
+ Advertisement message. Routers MAY perform this initial reachability
+ confirmation, but this might not scale in all environments.

 

[5/11/04 Update (from authors' conference call)]:

We believe that a more natural point in the document to discuss this issue

could be in an "encapsulation" section in section 7 of the document. (This

could be done in 1-2 sentences.) There was no consensus whether a

change is necessary.

 

[5/11/04 Update (from Mohit Talwar -seconded by co-authors)]:

Proposes moving the text that specifies address mapping from the current

section 8.4 to a new subsection in section 7 on "Encapsulation". Also, move

second paragraph in section 8.4 to end of current section 8.5 and delete

section 8.4. Proposed text follows:

 

+ 7.x Encapsulation

+ ISATAP addresses are mapped to a link-layer address by a static
+ computation, i.e, the last four octets are treated as an IPv4 address.

+

+ ...

+

+ 8.4 Neighbor Unreachability Detection

+

+ Hosts SHOULD perform Neighbor Unreachability Detection ([RFC2461], section 7.3).

+ Routers MAY perform neighbor unreachability detection, but this might not scale in all

+ environments.

+

+ After address resolution, hosts SHOULD perform an initial reachability confirmation

+ by sending Neighbor Solicitation message(s) and receiving a Neighbor Advertisement

+ message. Routers MAY perform this initial reachability confirmation, but this might

+ not scale in all environments.

 

[5/26/04 Update (from Fred Templin)]:

Updated resolution status from "Text Proposed" to "Accepted".

Resolution: Accepted

 

 

Issue 15: PRLs only maintained on host interfaces
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

 

Section 7.2:

 

Perhaps is should here be clarified that the PRLs only

are maintained on host interfaces and as such this check does not

apply to router interfaces.

 

[4/26/04 Update (from Fred Templin)]:

For any ISATAP interface that does not configure a PRL, the 2nd check

in section 7.2 is a NO-OP, so no clarification needed in section 7.2.

Further, it may be worthwhile to specify the following additional

decapsulation check for Isatap host interfaces:

- destination address should be an Isatap Address.

 

[4/26/04 Update (from Fred Templin)]:

Obviated by the current text of section 7.2. For further clarification, the

final sentence of that section could add a phrase about whether a packet

"belongs to" an ISATAP interface, e.g.:

 

  "Packets for which the IPv4 source address is incorrect for this ISATAP

   interface (or, that do not belong to this ISATAP interface) are checked

   to determine whether they belong to another tunnel interface."

 

[4/27/04 Update (from authors' conference call)]:

We are not convinced that any change is necessary; the

current text of section 7.2 is sufficient.

 

[5/05/04 Update (from Karen Nielsen)]:

OK.

 

[5/07/04 Update (from Fred Templin)]:

Resolution updated from "Possible Reject" to "Reject".

Resolution: Reject

 

 

Issue 16: Multicast emulation and DAD, Unsolicited RAs
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 2
Section: 
Rationale/Explanation of issue:

 

 

Section 8 general:

 

I miss a section stating that

multicast emulation isn't considered and that DAD

shouldn't be performed as part of address autoconfiguration.

 

[4/26/04 Update (from Fred Templin)]:

Beginning in the -11 version of the spec, there was a subsection on

DAD that was subsequently removed; this could be added back

under "Addressing Requirements" section 6.3 as:

 

"6.3 Duplicate Address Detection

 

Duplicate Address Detection ([RFC2462], section 5.4) is not required for

ISATAP addresses, since duplicate address detection is assumed already

performed for the IPv4 addresses from which they derive."

 

[4/27/04 Update (from authors' conference call)]:

There is existing precedence in NBMA specs (i.e., RFC3056) for

remaining silent on DAD. The above text could be added back if

we were to revise the spec, but given the existing precedent we

don't see the need.

 

[5/05/04 Update (from Karen Nielsen)]:

So you don't want to say anything about how

address auto configuration is done on Isatap host interfaces except for

how the link-local address and the link identifier is constructed - ??

 

[5/10/04 Update (from Fred Templin)]:

Could specify a limited set of multicast mappings, including the manner in

which the Solicited-node Multicast address in Neighbor Solicitation messages

is mapped and example mappings for multicast addresses of on-link routers,

servers and relays.

 

A new section 6 subsection on "Address Mapping -- Multicast" could be

added. Proposed text follows:

 

+ 6.x Address Mapping -- Multicast

+ For multicast packets sent on ISATAP interfaces:

+ - for Neighbor Solicitation messages ([RFC2461], section 4.3)
+   with an ISATAP address in the Target Address and a Solicited-
+   Node Multicast ([RFC3513], section 2.7.1) destination address,
+   the link-layer address is determined as for unicast address
+   mapping on the Target Address.
+
+ - for packets with multicast destination addresses that target

+   on-link routers, servers, or relays, e.g., the link-local scope

+   All Routers Multicast address ([RFC3513], section 2.7.1),

+   the All-DHCP_Relay_Agents_and_Servers address
+   ([RFC3313], section 5.1), etc., the link-layer address is
+   taken from V4ADDR(i) for some PRL(i) (see: section 8.1). The

+   manner of selecting PRL(i) is up to the implementation.
+
+ - other multicast mappings (and mechanisms for generalized

+    multicast emulation) are out of scope.

 

 

[5/11/04 Update (from authors' conference call)]:

We believe in remaining silent on multicast, as for 6to4. A separate

future document on "ISATAP multicast" could cover this.

Resolution: Reject

 

 

Issue 17: Unsolicited RAs on ISATAP interfaces
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 2
Section: 
Rationale/Explanation of issue:

 

 

Section 8.2:

 

"Unsolicited Router Advertisements are not sent on Isatap interfaces"

could be added for clarity.

 

[4/26/04 Update (from Fred Templin)]:

Mandating that advertising ISATAP interfaces of routers SHOULD/MUST

NOT send unsolicited Router Advertisements could allow the receipt of

Router Advertisements to serve as "hints of forward progress" for

Reachability Confirmation ([RFC2461], section 7.3.1).

 

[4/27/04 Update (from authors' conference call)]:

We have the existing precedent for remaining silent on unsolicited

RAs from RFC3056.

 

[5/05/04 Update (from Karen Nielsen)]:

OK - Though

The only mentioning of RA/RSs in 3056 was to refer to

a section of RFC2893 (now deprecated) which stated explicitly that

no aspects of ND (except for link-local addresses) should apply to

6to4 interfaces (as uni-directional automatic tunnel interfaces).

 

I don't get the precedence.

 

Isatap seems to have no need for unsolicited RAs and the security situation

as well as the reachability situation may be easier without them, but this

is a small issue and certainly not worth a fight.

 

[5/05/04 Update (from authors' conference call)]:

We don't see sufficient reason for any change in this.

Resolution: Reject

 

 

Issue 18: Mechanisms for PRL population
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

 

Section 8.3.2:

Perhaps it would be worthwhile to specify one (or several)

MUST be supported mechanism(s) for PRL population.

 

A standard FQDN identifier to use for DNS record lookups

should be specified, e.g., "isatap.<domain_name>", where

<domain_name> is the DNS suffix configured on the underlying

IPv4 interface.

 

[4/26/04 Update (from Fred Templin)]:

Beginning in version -04 of the spec, there was similar text on

determining the FQDN for PRL resolution. See: section 5.2.1 of:

 

http://www.geocities.com/osprey67/isatap/isatap-04.txt

 

Alternate proposal could be to add a phrase to the end of the

second sentence of the current section 8.3.2 such as:

 

"FQDNs are established via manual configuration or an unspecified

 alternate method, but the convention "isatap.domainname", where

 "domainname" is the DNS suffix configured on the underlying IPv4

 interface, SHOULD be supported."

 

[4/27/04 Update (from authors' conference call)]:

Text similar to that proposed appeared in earlier versions of the spec,

however the working group could not agree on any mandatory mechanisms.

See: Section 9 for best current practice recommendations for site administrators.

 

[5/05/04 Update (from Karen Nielsen)]:

How about specifying some possibly (if not mandated) mechanisms in detail then ??

 

[5/1/04 Update (from authors' conference call)]:

Please see our response from 4/27/04. We believe that it would be

difficult to gain consensus on any additional details for even optional

mechanisms.

Resolution: Reject

 

 

Issue 19: Validity check for RAs 
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

 

Section 8.3.3:

The following check should also be applied to RAs:

- the ipv6 source address is an

Isatap address that embeds the Ipv4 source address

in its interface identifier.

 

(this is not ensured by the "or'ed" rules in 7.2).

 

[4/26/04 Update (from Fred Templin)]:

The validity checks for RAs are performed at layer 3, but the IPv4

source address is discarded during decapsulation at layer 2.5 and therefore

not available to satisfy the proposed check. As long as the PRL(i) always

uses an ISATAP address that embeds V4ADDR(i) as the IPv6 source,

the "or'ed" rules for decapsulation in section 7.2 are already sufficient to

filter illegal RAs.

 

[4/27/04 Update (from authors' conference call)]:

We believe that security considerations adequately covers ip-protocol-41

filtering such that no further specification is needed.

 

[5/05/04 Update (from Karen Nielsen)]:

OK - It is however not true, as stated, that the PRL check is sufficient

to filter out illegal RAs. But you may say that if you trust the PRL, then you trust

it also not to send bogus RAs. For future security considerations perhaps.

 

[5/05/04 Update (from authors' conference call)]:

We agree with the above statement (as also stated in our 4/27/04 update)

and that this could go in a future security considerations document.

Resolution: Reject

 

 

Issue 20: Address Resolution and NUD 
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

Section 8.4:

From a security perspective

as well as from an implementation perspective

I would like to see this section strengthened a bit

along the following lines:

 

IPv6 Address resolution on Isatap interfaces consists of two steps:

- Link-layer address resolution

- IPv6 address reachability confirmation

 

Link-layer address resolution on Isatap interfaces

is performed by static computation from the Isatap Interface identifier

of the next-hop Isatap address.

 

[4/26/04 Update (from Fred Templin)]:

Already covered under section 8.4.

 

[4/29/04 Update (from authors'  conference call)]:

No change needed.

Link-layer addresses in Neighbor cache entries on Isatap Interfaces

MUST NOT be used unless they pass the following validity check:

* Link-layer address must correspond to the Ipv4 address embedded within

the Isatap interface identifier of the neighbor address.

 

[4/26/04 Update (from Fred Templin)]:

Same as for issue #22; see the proposed resolution under issue #22.

 

[4/29/04 Update (from authors'  conference call)]:

No change needed.

IPv6 address reachability confirmation is performed by sending

unicast Neighbor Solicitation

messages and receiving a Neighbor Advertisment message.

 

[4/26/04 Update (from Fred Templin)]:

Already covered under section 8.4.

 

[4/29/04 Update (from authors'  conference call)]:

No change needed.

During address resolution then a neighbor entry is considered

in INCOMPLETE state until Reachability Confirmation in form

of a solicited Neighbor Advertisement has been received.

 

[4/26/04 Update (from Fred Templin)]:

It doesn't seem that there is a need to define specific state

transitions for neighbor cache entries on ISATAP interfaces.

As long as an implementation is consistent with how it handles

NUD on ISATAP interfaces, there should be no interoperability

issues and, hence, no need for state handling specifications.

 

[4/29/04 Update (from authors'  conference call)]:

Agree with 4/26/04 update, i.e., no change needed.

For security and scalability reasons the

IPv6 address reachability Confirmation step SHOULD be omitted

on Router Interfaces.

[[FOR DISCUSSION: This behavior could be configurable on Router interfaces.

in trusted environments it could be useful to have NUD on the router also.

Default should be not to perform the reachability step]]

 

[4/26/04 Update (from Fred Templin)]:

A possible clarification could be to change the last sentence of section 8.4 to:

 

"Routers MAY perform this initial reachability confirmation, but this might

 not be secure and scalable in all environments."

 

[4/29/04 Update (from authors'  conference call)]:

We believe that the current text of 8.4 and 8.5 adequately address the issue.

Host SHOULD perform the IPv6 address reachability step when performing

address resolution.

If the IPv6 address reachability step is omitted, NUD will not succeed.

 

[4/26/04 Update (from Fred Templin)]:

Whether/not the initial reachability confirmation is performed, the -21

spec uses the specification from ([MECH], section 3.8) that says: "nodes

MUST accept and respond to the probe packets used by NUD (sic)".

Therefore, we have the necessary mechanism to support NUD.

 

[4/29/04 Update (from authors'  conference call)]:

We don't believe there is anything in this that would necessitate a

change to the spec.

 

[5/05/04 Update (from Karen Nielsen)]:

The reference to [MECH] wrt NUD doesn't apply

since the bidirectional tunnels

of [MECH] support multicast and the Isatap tunnels doesn't.

 

[5/11/04 Update (from authors'  conference call)]:

We agree that the wording of ([RFC2893], section 3.8) is confusing.

But, ISATAP interfaces take as normative reference all of RFC2893(bis),

section 3 which provides unambiguous guidance on NUD.

 

The multicast aspect of the comment is irrelevant, since NUD does

not use multicast.

Resolution: Reject

 

 

Issue 21: SENDPS Implications for ISATAP 
Submitter: Karen Nielsen
Submitter email address: karen.e.nielsen@ericsson.com
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

 

Section 10:

 

You may wish to take the following observations into consideration:

 

[4/26/04 Update (from Fred Templin)]:

The suggestions below appear to be the makings of a new document

on "Security Considerations for ISATAP", i.e., similar to:

 

www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt

 

See below for specific comments:

A number of the threats described in [SENDPS] on Isatap ND are

non-applicable to and/or easily preventable, Indeed:

 

4.1.1. Non-applicable given the above mentioned validity check

on neighbor cache entries - that is:

Link-layer addresses in Neighbor cache entries on Isatap Interfaces

MUST NOT be used unless they pass the following validity check:

* Link-layer address must correspond to the Ipv4 address embedded within

the Isatap interface identifier of the neighbor address.

 

[4/26/04 Update (from Fred Templin)]:

Same as for proposed resolution of issue #22.

 

[4/29/04 Update (from authors' conference call)]:

See our response to this in issue #20 and #22..

4.1.3: Non-applicable if DAD is omitted

 

4.2.1: Non-applicable given that a trust worthy PRL population

mechanism is deployed.

 

4.2.2:

Threat may be prevented all together by specifying that

an Isatap host interface MUST NOT operate with a non-zero PRL list.

That is, host-to-host only scenario not considered.

 

[4/26/04 Update (from Fred Templin)]:

Suggestions look reasonable, but for base specification or seperate

"Security Considerations for ISATAP" document?

 

[4/29/04 Update (from authors' conference call)]:

We agree with points 4.1.3 and 4.2.1, but we believe that better

mitigations exist for 4.2.2.

4.2.3:

Limited to the time in between successive refreshments of the PRL

given that a trust worthy PRL population

mechanism is deployed.

 

4.2.4

One may want to consider eliminating 4.2.4 of [SENDPS] simply

(and boldly) by disallowing the redirect functionality on Isatap interfaces.

 

[4/26/04 Update (from Fred Templin)]:

Suggestion looks reasonable, but for base specification or seperate

"Security Considerations for ISATAP" document?

 

[4/29/04 Update (from authors' conference call)]:

We don't believe this issue is necessarily different than the

situation of malicious last-hop router.

The risk of not supporting the redirect functionality is very small;

The Redirect function is generally used to:

Inform Isatap hosts of destinations with Isatap prefixes

that are directly reachable by ISATAP tunneling from the IPv4 site of the Isatap host.

Redirect Isatap hosts to a better first-hop on-link Isatap router for a specific destination

However, in the first situation above, a correct functioning Isatap host

will learn of the on-link ISATAP prefixes from the RS/RA exchange performed

periodically with all routers from its, also periodically updated, PRL list,

and hence only a limited amount of time can elapse before it would correct its behavior.

The second situation is probably not relevant for ISATAP scenarios given that

router-to-router tunneling isn't supported. Indeed it is our experience that

routers typically only send Redirect messages indicating better

first-hop router if the egress interface towards this better

first-hop router for the packet in question is the same as

the ingress that it received the packet on. In ISATAP scenarios,

the ingress interface would be an ISATAP interface and

such an interface cannot be used for Router-to-Router forwarding.

 

4.3.2:

Non-applicable if the Ipv6 address reachability step of

address resolution isn't implemented on Isatap router interfaces.

 

Security threats on Isatap ND in secured corporate intranet/enterprises :

------------------------------------------------------------------------

 

Given that 4.2.2 and 4.2.4 are prevented by specifying a particular behavior

on Isatap interfaces (as indicated right above). Then in accordance with

the table in section 4.4. of [SENDPS] only 4.3.1 remain a real concern

in this environment. This is for further investigation.

 

Security threats on Isatap ND in IPv4 source proof and protocol-41 perimeter guarded sites:

-------------------------------------------------------------------------------------------

 

The additional security treats associated with IPv6 neighbor discovery

described in [SENDPS] for the most part are non-applicable or

can be prevented by simple measures to

Isatap host and routers in sites that are

guarded against ip-protocol-41 at the perimeter

and for which IPv4 source spoofing isn't possible.

 

A prime example of an IPv4 source proof and protocol-41 perimeter guarded site

is the network a mobile operator where the GGSN have

activated IPv4 address spoofing protection

and which in addition implement ip-protocol-41 filtering at the edges.

 

Note that IPv4 source address proof and ip-protocol-41

site perimeter filtering together with the Isatap decapsulation rules

effectively establish source proofing on IPv6 Isatap addresses.

 

The following refer to the threats described in [SENDPS]:

4.1.2: Given Ipv4 source address proof,

this attack may be prevented by requirering the following validity check

to be applied to received NA messages on Isatap interfaces:

In addition to the validity checks given in RFC 2461 a NA message must

pass the following validity check:

* the IPv6 address in the target field must

be an Isatap address which embeds the v4 source address.

 

However it should be noted that this check will disallow ND proxy functionality

on Isatap sites, whether that's undesirable is not clear to me.

 

(one implication of course would be that the MIpv6 HA service cannot be provided

on Isatap sites but one would never want to do that anyway I think).

 

4.2.5+4.2.6+4.2.7:

Non-applicable given IPv4 source address spoofing prevention

if trustworthy PRL population mechanism is deployed.

 

4.2.2:

Spoofed RA message with zero-lifetime is not applicable.

As mentioned above this threat may be prevented all together by specifying that

an Isatap host interface MUST NOT operate with a non-zero PRL list.

 

[4/26/04 Update (from Fred Templin)]:

For base specification, or for separate "Security Considerations

for ISATAP" document?

 

[4/29/04 Update (from authors' conference call)]:

See earlier response to 4.2.2.

4.2.3:

Limited to the time in between successive refreshments of the PRL

for the same reasons as 4.2.1.

In addition then compromising the Isatap router itself

is a doubtful scenario in carefully managed networks

such as e.g. 3GPP/3GPP2 and enterprise networks.

 

4.2.4:

Is limited by Ipv4 source address spoofing prevention.

In addition then compromising the Isatap router itself

is a doubtful scenario in 3GPP/3GPP2 and enterprise networks

May be prevented altogether by disallowing the redirect

functionality on Isatap interfaces as mentioned above.

 

4.3.1:

Non-applicable by Ipv4 source address spoofing prevention.

 

[4/29/04 Update (from authors' conference call)]:

The above discussion provides useful and good analysis. We have gone through

the points, and believe that many are valid and could be made into a separate

document on ISATAP security. We believe that the base spec already provides

sufficient guidance for implementers and site administrators.

 

[5/05/04 Update (from Karen Nielsen)]:

OK - for future security considerations perhaps.

 

[5/07/04 Update (from Fred Templin)]:

Resolution updated from "Possible Reject" to "Reject".

Resolution: Reject

 

 

Issue 22: Neighbor Cache Entries for ISATAP interfaces
Submitter: Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

 

I've some problem with section 8:

...

8. Neighbor Discovery for ISATAP Interfaces

ISATAP nodes use the neighbor discovery mechanisms specified in

[RFC2461] to create/change neighbor cache entries. ISATAP interfaces

also implement the following specifications:

...

 

I don't see how a neighbor cache entries would get created. You cannot

run normal RFC2461 neighbor discovery on ISATAP interface to detect

link layer addresses: ISATAP interface does not support multicast!

 

I think all references to neighbor cache could be removed (there is no

need for link layer addresses). Like, in section 8.4

 

[4/27/04 Update (from Fred Templin)]:

Proposal is to change first two sentences of section 8 to:

 

"ISATAP nodes use the mechanisms in [RFC2461] that apply

 to NBMA interfaces and also implement the following specifications."

 

[4/27/04 Update (from authors' conference call)]:

The conceptual sending algorithm in (RFC2461, section 5.2) applies

equally to ISATAP interfaces. This includes creating/changing neighbor

cache entries.

...

8.4 Address Resolution

The specification in ([RFC2461], section 7.2) is used. ISATAP

addresses for which the neighbor's link-layer address cannot

otherwise be determined (e.g., from a neighbor cache entry) are

resolved to link-layer addresses by a static computation, i.e., the

last four octets are treated as an IPv4 address.

...

 

Change above just into

 

...

8.4 Address Resolution

ISATAP addresses are resolved to link-layer addresses by a static

computation, i.e., the last four octets are treated as an IPv4

address.

 

[4/26/04 Update (from Fred Templin)]:

The text in question is a known artifact that was scheduled for

removal prior to publication of -21.

 

[4/27/04 Update (from authors' conference call)]:

We believe the text is correct either way, with slight preference

toward Markku's suggestion.

...

 

A corollary to above is: ISATAP IPv6 "nexthop address" is always based

on one of the PRL addresses.

 

[4/26/04 Update (from Fred Templin)]:

Not necessarily correct; this doesn't belong in the spec.

 

[4/27/04 Update (from authors' conference call)]:

We disagree with the statement.

 

[5/05/04 Update (from Markku Savela)]:

For 22-23, I still don't agree with the conclusion:

 

[4/27/04 Update (from authors' conference call)]:

The conceptual sending algorithm in (RFC2461, section 5.2) applies

equally to ISATAP interfaces. This includes creating/changing

neighbor cache entries.

 

If you check RFC2461 5.2...

...

Once the IP address of the next-hop node is known, the sender

examines the Neighbor Cache for link-layer information about that

neighbor. If no entry exists, the sender creates one, sets its state to

INCOMPLETE, initiates Address Resolution, and then queues the data

packet pending completion of address resolution. For multicast-

capable interfaces Address Resolution consists of sending a Neighbor

Solicitation message and waiting for a Neighbor Advertisement. ...

...

 

Yes, NCE is created, but in INCOMPLETE state. And, in ISATAP draft,

there is nothing to advice how it will change from that state. RFC2461

specifies that only for multicast capable links.

 

Referencing NBMA RFC2491 is no help. It again relies on MARS (RFC2022)

for ND. This seems like a huge overkill for ISATAP. A simpler solution

would be better.

 

For example, the problem might be simply solved by stating:

 

On ISATAP interface, NCE entry created by RFC2461 5.2 process into

INCOMPLETE state is implicitly set to REACHABLE state.

 

[5/05/04 Update (from Dave Thaler)]:

That is the intended behavior yes. This is no different from any other

interface that uses algorithmic mappings, such as 6to4.

 

[5/05/04 Update (from Markku Savela)]:

However, this is not how standard IPv6 stack would work. This requires

either change in the stack, some special flag for ISATAP type

interface, or the ISATAP driver needs to have a way to modify the

state of the neighbor cache in the stack.

 

[5/05/04 Update (from Dave Thaler)]:

There's nothing ISATAP-specific here. ISATAP is just another

link-layer media in the class of algorithmically-mapped ones.

 

[5/05/04 Update (from Markku Savela)]:

All I'm trying to say, there is a "gap" in the specification: no

advice how INCOMPLETE magically changes into REACHABLE (and usable

NCE).

 

[5/05/04 Update (from Dave Thaler)]:

In my opinion, the "gap" would best be filled in a generic spec like

2461bis or 2893bis.

 

[5/05/04 Update (from Markku Savela)]:

On the other hand, I also question the usefulnes of the NCE entries

for anything else but routers in PRL list. What purpose they serve for

ISATAP?

 

[5/05/04 Update (from Dave Thaler)]:

Neighbor Unreachability Detection, same as with 6to4.

 

[5/05/04 Update (from Markku Savela)]:

Why would you talk to neighbors that are reachable directly by

IPv4 through ISATAP?

 

[5/05/04 Update (from Dave Thaler)]:

Because the application wants to use IPv6, same as with any

transition mechanism.

 

[5/05/04 Update (from Karen Nielsen)]:

> Neighbor Unreachability Detection, same as with 6to4.

 

As previously discussed, NUD will not work if static address computation alone

results in an NCE entry in REACHABLE STATE.

 

I don't believe this is the same for 6to4 interfacesas, NUD is not specified

to be performed on these interfaces.

 

[5/05/04 Update (from Dave Thaler)]:

> As previously discussed, NUD will not work if static address computation alone

> results in an NCE entry in REACHABLE STATE.

 

Two responses:

1) yes it does. NUD kicks in after the entry goes to STALE.

2) My mistake when I said creating in REACHABLE was intended (although

as above, NUD isn't broken, it's just delayed). It is better to

create it in the STALE state (immediately moving to PROBE since

you're sending a packet), and in fact this is what the co-authors

had discussed, not creating in REACHABLE.

 

> I don't believe this is the same for 6to4 interfacesas, NUD is not specified

> to be performed on these interfaces.

 

Yes it is. See section 3.1 of RFC 3056 (6to4).

 

5/05/04 Update (from Karen Nielsen)]:

> Two responses:

> 1) yes it does. NUD kicks in after the entry goes to STALE.

> 2) My mistake when I said creating in REACHABLE was intended (although

> as above, NUD isn't broken, it's just delayed). It is better to

> create it in the STALE state (immediately moving to PROBE since

> you're sending a packet), and in fact this is what the co-authors

> had discussed, not creating in REACHABLE.

 

I agree that the NUD algorithm kicks in,

but I believe that it will have no effect unless

the reachability of the peer is

confirmed as part of the address

resolution step - even in STALE, DELAY, PROBE packets are send,

only in INCOMPLETE they are not.

 

If the peer isn't reachable then yes

NUD will ensure that the NCE at some point is deleted

which merely means that static address resoltion will be performed anew

when the next packet arrives, a NCE will be created in STALE/REACHABLE

and we can start the NUD cycle once more while we continuosly are transmitting packets.

This regardless of whether the NCE initially is put in REACHABLE or

in STALE state.

 

Or - what am I missing ?

 

> > I don't believe this is the same for 6to4 interfacesas, NUD is not

> > specified

> > to be performed on these interfaces.

>

> Yes it is. See section 3.1 of RFC 3056 (6to4).

 

Which refers to 2893 which says that NUD does not apply to

unidirectional automatic tunnels - but only to bidirectional configured

tunnels which 6to4 explicitly is said not to be - ?

BTW - exactly this reference of 3056 to 2893 has aways puzzled me - if would

have been easier simply to state that ND didn't apply than

to refer to another document which says just that.

Which again may mean that I am reading it wrong as you seem to think.

 

[5/11/04 Update (from authors' conference call)]:

We agree that the wording of ([RFC2893], section 3.8) is confusing.

But, ISATAP interfaces take as normative reference all of RFC2893(bis),

section 3 which provides unambiguous guidance on NUD. 

 

[5/11/04 Update (from Tim Gleeson)]:

I think issue #22 has several subpoints that we should pull out, including

at least:

A) Can NCE's ever get created?

B) What state should an NCE start in? If not INCOMPLETE, in what doc should

the initial state be specified?

C) What use are NCE's? Are NCE's effective for NUD?

D) If we want NUD, is it implicitly/explicitly specified and if so, where?

E) Address resolution specification, notably multicast addresses

 

[5/11/04 Update (from Fred Templin)]:

> A) Can NCE's ever get created?

 

Yes it can; a NCE can get created:

 

   1) In the INCOMPLETE state when sending a first packet to a neighbor

       via address resolution as for ordinary multicast-capable interfaces. (ISATAP

       interfaces can support a *limited* multicast capability, including a means for

       mapping the Solicited Node Multicast address to a Link layer address.

       Thus, they can perform "Address Resolution emulation".)

 

  2) In the STALE state when sending a first packet to a neighbor if the

      implementation has a way of performing this "specialized" step for ISATAP

      interfaces. This could be done via a special case statement in the IP layer,

      in the ISATAP link-layer driver, etc.

 

  3) In the STALE state upon receipt of a NS, RS, RA, or Redirect.

 

> B) What state should an NCE start in?

 

Implementations can use "Address Resolution emulation", i.e., create a NCE in

the INCOMPLETE state, send a NS to the Solicited Node Multicast address

of the neighbor tunneled to the unicast IPv4 address of the neighbor, and keep

a short queue of data packets while waiting for an NA response.

 

An alternate approach would be to create the NCE in the STALE state and

immediately send data packets to the known link-layer address of the neighbor,

since subsequent reachability confirmation from the neighbor (and/or going to

the DELAY/PROBE states, sending unicast NSs and getting an NA back)

will quickly cause the NCE to go to the REACHABLE state. This would

be more efficient than the Address Resolution emulation method.

 

The problem with the alternate approach occurs when a neighbor is

unreachable but the original source continues to send. In that case, the

NCE will be created, cycle through the states, and be deleted indefinitely.

Coupling this "create-in-STALE-state" method with an initial unicast NS/NA

exchange provides timely reachability confirmation (if the neighbor is indeed

reachable), but will still cycle through the states with no feedback to the

original source if the path to the neighbor subsequently fails. In short, since

the create-in-STALE-state method does not keep a queue of data packets

pending reachability confirmation, a different method (e.g., link-specific

information that a path to a neighbor has failed) is needed to return ICMP

feedback to the original source.

 

> If not INCOMPLETE, in what doc should

> the initial state be specified?

 

Does not seem like material for the base specification - rather for an "NBMA

implementor's guide" document (sic). Such a document could be an IETF

informational/BCP category submission, or could just be a whitepaper on

a well-know www page (such as the current document).

 

> C) What use are NCE's?

 

In the Address Resolution emulation method, to detect when a path to a

neighbor is failing or has failed and send ICMP feedback to the original

source based on a queue of pending packets, as for any IPv6 interface

over which ND applies. In the create-in-STALE-state method, possibly

no use, since the only path failure feedback to the original source would

come from link-specific information, i.e., since no queue of pending packets

is kept. But, in this case, there would not seem to be a need for NUD

anyway.

 

> Are NCE's effective for NUD?

 

For the Address Resolution emulation method - yes.

For the create-in-STALE-state method - possibly not.

 

> D) If we want NUD, is it implicitly/explicitly specified and if so, where?

 

If Address Resolution emulation method is used, NUD is performed exactly

as in RFC2461, section 7.3 assuming the Solicited Node Multicast address

in a Neighbor Solicitation is mapped to a unicast link-layer (IPv4) addresses.

 

> E) Address resolution specification, notably multicast addresses

 

See issue 16.

 

[5/11/04 Update (from authors' conference call)]:

> A) Can NCE's ever get created?

 

Up to the implementation.

 

> B) What state should an NCE start in? If not INCOMPLETE, in what doc should

> the initial state be specified?

 

We suggest starting in the STALE state. But, since this is not specific

to ISATAP (and, since ISATAP does not require NCEs), we suggest

that this go in RFC2461(bis) or a future document discussing the class

of interface that use static mapping for address resolution.

 

> C) What use are NCE's? Are NCE's effective for NUD?

 

A naive implementation of RFC2461 will spin through the NCE states and

be ineffective, but implementations can use, e.g., negative cache entries

for effective NUD on such interfaces.

 

> D) If we want NUD, is it implicitly/explicitly specified and if so, where?

 

No change for the ISATAP spec in this regard.

 

> E) Address resolution specification, notably multicast addresses

 

See issue 16.

 

[5/11/04 Update (from authors' conference call)]:

We agree that references to the neighbor cache entries could

be removed, since NCE's are an implementation mechanism.

(RFC3056 took the same approach.)

 

[5/26/04 Update (from Fred Templin)]:

Updated resolution status from "Text Proposed" to "Accepted".

Resolution: Accepted

 

 

Issue 23: Type of IPv6 interface in ISATAP interface definition
Submitter: Markku Savela
Submitter email address: msa@burp.tkv.asdf.org
Date first submitted: April 20, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 2
Section: 
Rationale/Explanation of issue:

 

I was hoping that the ISATAP interface would look like standard IPv6

interface to the stack. The above procedure is not what stack would do

on any interface. The currently defined choices for "standard" IPv6

interfaces are:

 

1) Point-to-point (no addresses on the link)

 

2) "Ethernet type", link layer addresses, RFC2461 style neighbor

discovery (which relies on multicast).

 

[4/27/04 Update (from authors' conference call)]:

The correct RFC2461-specified interface type for ISATAP is

"non-broadcast multi-access (NBMA)". This could be clarified under

"Terminology" by changing "point-to-multipoint" to "non-broadcast

multi-access (NBMA)" under the ISATAP interface definition, but

we don't see this as necessary.

 

[5/11/04 Update (from authors' conference call)]:

We agree that this could be changed as per 4/27/04 update.

 

[5/26/04 Update (from Fred Templin)]:

Updated resolution status from "Text Proposed" to "Accepted".

Resolution: Accepted

 

 

Issue 24: Splitting the PRL into Ingress and Egress Lists
Submitter: Fred L. Templin
Submitter email address: fred.templin@nokia.com
Date first submitted: April 27, 2004
Reference:
Document: isatap-21.txt
Comment type: Technical
Priority: 1
Section: 
Rationale/Explanation of issue:

 

The PRL gives the IPv4 addresses of on-link routers. The definition for

"ISATAP link" needs to be clearly understood before the PRL can be

clearly understood:

 

- from the perspective of a host that sends packets to the next-hop on an

ISATAP interface, the extent of the ISATAP link depends on the first NAT

(if any) along the path toward the final destination that would modify the IPv4

destination. In other words, from the perspective of a node sending packets

on an ISATAP interface, the first NAT that would modify the IPv4 destination

occurs in the same topological location as the next-hop router at the egress

edge of the ISATAP link.

 

- from the perspective of a host that receives packets from a last-hop on an

ISATAP interface, the extent of the ISATAP link depends on the final NAT

(if any) that would modify the IPv4 destination before the packet is delivered to

the host. In other words, from the perspective of a node receiving packets on an

ISATAP interface, the final NAT that would modify the IPv4 destination before

the packet is delivered to the host occurs in the same topological location as the

last-hop router at the ingress edge of the ISATAP link.

 

The extent of the ISATAP link is therefore asymmetric based on ingress vs. egress

directions. The current Potential Routers List definition should be clarified to explain that

it applies ONLY to the egress path, and a new list: "Ingress Router List (IRL)" should be

added. The text of section 7.2 (decapsulation) should be changed to deal with the IRL

only, and the text of section 8.3 should be changed to deal with both lists. Change

suggestions are:

 

1) In section 7.2, change the second "or'd" rule to:

 

  - the IPv4 source address is a member of the Ingress Router List (IRL)

    (see section 8.1).

 

2) Change section 8.1 to read:

 

   "8.1 Conceptual Model of a Host

 

   To the list of Conceptual Data Structures ([RFC2461], section 5.1),

   ISATAP interfaces add:

 

   Potential Router List (PRL)

      A set of entries about egress routers; used to support router and

      prefix discovery. Each entry ("PRL(i)") has an associated timer

      ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that represents

      an egress router's advertising ISATAP interface.

 

   Ingress Rotuer List (IRL)

      A list of IPv4 addresses about ingress routers; used for ingress

      filtering during decapsulation (see: section 7.2). Each IPv4 address

      represents an ingress router's forwarding ISATAP interface.

 

3) In section 8.3.2, first sentence, change the phrase: "a DNS fully-

    qualified domain name (FQDN)" to: "DNS fully-qualified domain

    names (FQDNs)".

 

4) Add a new section (section 8.3.3) on Ingress Router List Initialization:

 

   "8.3.3 Ingress Router List Initialization

 

    ISATAP nodes initialize an ISATAP interface's IRL with IPv4 addresses

    discovered based on their detection of IPv4 network attachment. For ISATAP

    interfaces that configure a locator set comprising global IPv4 addresses, the

    IRL is initialized to the list of all global IPv4 addresses excluding the node's

    own address(es). For ISATAP interfaces that configure a locator set comprising

    private addresses, the IRL is initialized as for PRL initialization (see: section

    8.3.2). When an FQDN is used, the convention "isatap.domainname",

    where "domainname" is the DNS suffix discovered during detection of

    IPv4 network attachment, SHOULD be supported.

.

    After initializing an ISATAP interface's IRL, the node re-initializes the list

    as for reinitialization of the PRL. The node also re-initialized the list when

    when its the IPv4 network attachment changes, e.g., when the node moves

    to a new site, etc."

 

5) In section 10, change the 4th paragraph into *two* paragraphs as follows:

 

   "Another possible spoofing attack involves spurious ip-protocol-41

    packets injected from within an ISATAP link by a node pretending

    to be a router. The Ingress Router List (IRL) provides a list of IPv4

    addresses representing forwarding ISATAP interfaces of ingress

    routers that hosts use for ingress filtering.

 

    The Potential Router List (PRL) provides a list of IPv4 addresses

    representing advertising ISATAP interfaces of egress routers that

    hosts use for router and prefix discovery. Site administrators

    should ensure that the PRL is kept up to date, and that the

    resolution mechanism (see: section 9) cannot be subverted."

 

NOTE: With the above changes 1) thru 5), the document could do

a global change of  "potential router list" to "egress router list" for

greater clarity (optional).

 

[4/27/04 Update (from authors' conference call)]:

While it is possible to describe the PRL as comprising separable ingress

and egress components, this is not necessary for documenting the widely-

deployed implementations. Also, current practices have the ingress and

egress router functions combined in a single box (i.e., not "split" with an

IPv4 network between them), and this is correctly described by the current

PRL text. The suggestions could go as part of a separate document, but

not for the base specification.

Resolution: Reject