ND-Proxy Old Issues List

Last Updated: February 12, 2005

Document status

Here is a pointer to the latest specification:

draft-ietf-ipv6-ndproxy-01.txt

Previous versions:

draft-ietf-ipv6-ndproxy-00.txt
draft-thaler-ipv6-ndproxy-03.txt
draft-thaler-ipv6-ndproxy-02.txt
draft-thaler-ipv6-ndproxy-01.txt
draft-thaler-ipv6-ndproxy-00.txt

Old Issues List

Open Issues List

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: Missing details on STP over non-802 media
Submitter: Erik Nordmark
Submitter email address: erik.nordmark@eng.sun.com
Date first submitted: Vienna IETF
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: S
Section: Missing
Rationale/Explanation of issue:

One of the target scenarios is support over non-802 media such as PPP, but the mechanism of sending STP packets over non-802 media is not specified.

[DT comment]:

Discussed with Erik after the meeting the following.

Specify that IANA will assign

1) an IPv6 Next Header value for STP

2) a well-known IPv6 link-scoped multicast group for All-STP-Speakers.

STP packets are then sent in IPv6 link-scoped multicast packets, when used over non-802 media (only).

As an exception to the usual multicast forwarding rule, NDproxies will not forward any packets to this group. They will process the packets locally if they implement STP.

CP asked about STP over IPv4.

DT suggests anyone who needs to do STP over non-802 can just as easily put on an IPv6 header.

CP says this does not seem to be an elegant solution especially for IPv4 nodes that implement ARP proxy.

Resolution: Accepted in draft-01

Issue 2: make STP optional
Submitter: Pekka Savola
Submitter email address: pekkas@netcore.fi
Date first submitted: July 16, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: 1
Section: 2
Rationale/Explanation of issue:

Implementing STP should be optional.

At the Vienna meeting, someone also claimed it's even optional in the 802.1D spec.

[DT comment]:

I just checked the 802.1D spec to verify what that person claimed.

It says:

> 5.1 Static conformance requirements

>

> A MAC Bridge for which conformance to this standard is claimed shall

...

> h) Implement the Spanning Tree Algorithm and Protocol described in

> Clause 8, as specified in 8.7.

...

Hence it does not appear to be optional.  That said, I do agree that in the NDproxy spec it should be optional (perhaps a SHOULD).  The rationale is that I'd like the spec to be implementable by devices like a cell phone which has a PPP link externally and an Ethernet link to a PC. The chances of having a physical loop are so remote that it is not worth spending the silicon to implement STA.

[Proposed text makes it completely OPTIONAL]:

Loop prevention can be done done by having the proxy implement the
Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all
proxy interfaces. Loop prevention is OPTIONAL, and is useful only
if the proxy can be deployed in an environment where physical loops
are possible. For example, in a cell phone which proxies between a
PPP dialup link and a local Ethernet interface, it is typically safe
to assume that physical loops are not possible and hence there is
no need to support the Spanning Tree Protocol (STP).

If loop prevention is implemented, it is done as follows.
IEEE 802 interfaces use the protocol exactly as specified in [BRIDGE].
Operation of the Spanning Tree Protocol (STP) over other types of link
layers is done by encapsulating the STP frame in an IPv6 header as follows.
The Next Header field is set to [TBA by IANA], indicating that an
STP header follows. The Destination Address field is set to the
Link-scoped STP Multicast Group [TBA by IANA]. All proxies operating
on non-IEEE 802 media join this group so they will receive STP packets.
STP packets are never forwarded or proxied.

Resolution: Accepted in draft-01

Subsequent discussion...

[Pekka Savola]: If the user plugs three ND-proxies in a triangle or two (or more) ND-proxies in a loop, the everything breaks -- and the customer fixes the set-up or calls someone to fix it. Immediate failure, immediate fix. I see no problem with this. As it is, ND-proxy should never be enabled by default in any case.
[...]

I strongly believe we should get rid of the whole IEEE 802.1D spanning tree protocol hack from the protocol in the first place.

[Erik Nordmark]: elsewhere (in a mail on v6ops) you stated the concern that IPv6 might end up with consumer-class "routers" (devices that sit between different types of L2) that do v6-to-v6 NAT because that would be more plug and play than the alternatives hence we need an alternative like ndproxy (at least I think you made that argument).

Saying that ndproxy needs to be manually enabled and can't be enabled by default doesn't match this concern.

I also don't see how one can prevent consumers from connecting such devices in ways that form loops. It *might* be sufficient if the solution could detect loops and sound the alarm (and stop forwarding frames), but ndproxy can't even detect loops and shut itself off. Thus when loops are formed the result is that the consumer will see their network die (100% link utilization due to frames looping around forever; ndproxy doesn't decrement the hop count).
 

[Pekka Savola]: I don't personally think 100% link utilization is that bad a signal. It rather simply conveys that "oops-- I've done something wrong when I added the box there." and after it's removed all starts to work again -- intuitive. What would be worse is that some packets would work but some others not. Total connectivity loss is a good indicator of a problem :).

I think it would be possible to detect loops if we wanted really hard to do that. That might just lead to reinvention of the spanning tree protocol, though.

For example, the ND proxy could send in ND solicitation for its own IP address. If it hears back that solicitation on some other interface, it can conclude that someone is looping those packets and it should e.g. shut down completely.

[Hesham Soliman]: I think it's a bad signal, _if_ detected. I.e. An average user is not even going to know that they have 100% link utilisation. And _if_ they do, I actually think that neither the user, nor the help desk first line of support will have the faintest idea (having been a regular with help desk people that work for a couple of major operators in different countries).
 

[Jari Arkko]: I agree with Erik and Hesham that loop preventation is something that we may wish to have.
 

[Pekka Savola]: The user knows that all of his communication attempts fail. That's a good signal that there's something wrong. If the user knows nothing more of this, he calls helpdesk or some support, which may be able to identify the problem and eliminate it.

Or, the user could read the manual for the shiny box he bough, and notice a big warning text "DON'T LINK THESE BOXES EXCEPT IN SERIES UNLESS YOU DISABLE ND-PROXYING [and instructions how to do it]"

[Ole Troan]: I agree with Erik.

I see two alternatives:
1. ND proxy. Limited to single router, proxy from uplink to downlink. No need for loop detection.
2. Multilink subnet routing. Handles arbitrary topologies. Must handle loops.

publishing a specification for ND proxy with support for a restricted topology (multiple routers) without handling loops is just irresponsible.

[Fred Templin]: I really believe such devices will require mechanisms to support zero configuration and automatic topology discovery. A user should be able to just plug it in and have it work without needing a degree in network engineering to diagnose any number of esoteric problems that might crop up. This means that we need some form of loop prevention that is agile in terms of adapting to dynamic topology changes, doesn't unnecessarily disable interfaces as a means for loop prevention, and allows for neighbors to be reachable over possibly multiple interfaces.

In other words, we need something like the experimental protocols coming from the MANET wg (e.g., AODV, DSR, OLSR, TBRPF). Even better would be a unified mechanism that combines the best aspects of on-demand and reactive protocols.

[Erik Nordmark]: I think what we want is the complexity equivalent of plugging together electrical extension cords. Looking at Ethernet we don't have the male/female distinction on the plugs hence it is a lot easier to create Ethernet loops than power extension cord loops. Combining this with wireless makes it even more likely that there will be accidental loops.

[Pekka Savola]: But as discussed, rather light-weight loop detection mechanism could be added with relative ease: e.g., an ND option that would be added to identify the proxy (would increase the ND message size though == bad).

Another option that hasn't been explicitly mentioned which I just thought of could be reusing ND code. The ND proxy would send a NS message for an RFC3041 randomized address out on all its interfaces, and wait for a short period of time. If the same NS probe is heard back from any other interface, there is a reason to believe there is a loop somewhere. (This assumes that in this very short time frame, nobody else would be NS'ing specifically that address.)

[Erik Nordmark]: Put N of those boxes in a house, connect them in a loop, and turn of the power at the circuit breaker. When you power on they will first not forward frames (since if they did the detection doesn't prevent the loop) hence the loop detection will not detect the loop that is there, and then they will all enable forwarding of frames.

I think you will step by step end up implementing something which is close to the complexity of IEEE Spanning Tree Protocol if you want this to be robust.

Resolution: No change beyond previous resolution
See also: Issue 16, Loop prevention, revisited

Issue 3: Add requirements
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: September 30, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: 1
Section: 1.1
Rationale/Explanation of issue:

Add the following requirements.

a) Allow dynamic addition/removal of proxies, and nodes to the network without disrupting traffic.

b) The proxy should be able to interwork with a 802.1d compliant bridge.

[DT comment]:
Agree.  However in Vienna someone commented that they believed this was not a "requirement" per se, but rather a design decision.  Perhaps we could say it is a requirement to not BREAK existing 802.1d compliant bridges.

Resolution: Accepted in draft-01

Issue 4: IP address requirement
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: September 30, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: 1
Section: 1.2
Rationale/Explanation of issue:

Current text:

o Show up in a traceroute.

Proposed text:

 "Should not require assignment of an IP address. It implies that the bridge will not be visible in traceroute scans."

[Dave Thaler comment]:
Not quite. If you decrement the TTL/hop limit, you'll "show up" in traceroute, although if you send no ICMP errors you'll show up as "* * *" but a hop is visible. The point is that there's no requirement for a hop to show up at all. Whether there's an IP address or not makes no different if you don't decrement the hop limit. Classic bridges may or may not have an IP address now, but they won't show up in traceroute either way.

[Chirayu Patel also proposed:]
Section 3.3)
------------
A proxy device does not require a local IP address. However it will be convenient to configure the proxies remotely if they are assigned an an IP address.
Assignment of an IP address does not change the working of the proxy. It would require that the proxy to implement the more protocols (give reference to IPv4, IPv6 node requirements). The interface that has been assigned an IP address can be viewed as an internal interface.
The following high level diagram depicts the various functional blocks within a proxy that has been assigned an IP address.

[Dave Thaler comment]:

The above is too restrictive. That is certainly one valid implementation, but is not the only one.

It is just as legal for IPv4/IPv6 to run directly on the "external interfaces". Indeed our intent was to generally word the document as if the latter were the case, but not preclude the one you show.

Hence I am not satisfied with the above proposed text.

[Pekka Savola]:

FWIW, requiring IP address is OK by me.

[Dave Thaler]:

Proposed rejecting this at Minneapolis IETF, and just assume than an NDProxy is an "IPv6 Node" meeting all the requirements for IPv6 nodes.  No objections.

The rationale is that with the status going to Informational rather than Proposed Standard, we just need to describe things in the easiest to understand way.

[Chirayu Patel proposed clarifying text]:

"ND proxies will have to be assigned address (global, and link-local) if remote management is required, or STP will be executed in a non-802 environment, or if it is going to run any other application that will send, and receive data.  The actual method that will be used to assign addresses is outside of the scope of this document. RS/RA, DHCPv6, static configuration are some of the methods that may be used.  It may be possible to use a partial IPv6 implementation to save resources if the ND proxy will not originate any IPv6 packets."

[Dave Thaler proposed alternate clarifying text]:

"While it is possible that functionality equivalent to that described herein may be achieved by nodes which do not fulfill all the requirements in [NODEREQ], in the remainder of this document we will assume that an ND proxy is an IPv6 node as defined in that document."

Resolution: Rejected, clarifying text proposed

Issue 5: Don't clear override bit
Submitter: Dave Thaler
Submitter email address: dthaler@microsoft.com
Date first submitted: October 20, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: 1
Section: 2
Rationale/Explanation of issue:

From RFC 2461:

Proxy advertisements - A router willing to accept packets on behalf of a target address that is unable to respond to Neighbor Solicitations can issue non-Override Neighbor Advertisements.  There is currently no specified use of proxy, but proxy advertising could potentially be used to handle cases like mobile nodes that have moved off-link. However, it is not intended as a general mechanism to handle nodes that, e.g., do not implement this protocol.

Proper setting of the Override flag ensures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, and also ensures that the first advertisement for an anycast address "wins".

Proposal: Don't modify Override flag.

Rationale:

1) Clearing the Override bit slows down convergence when a node moves to another segment, as NAs from the proxy will not update neighbor caches on the old segment until the entry gets stale.

2) The first quote above allows for this case.

3) The reason for a proxy to clear it (ensuring that nodes give preference to non-proxy advertisements) shouldn't apply, given the loop free topology.

Resolution: Accepted in draft-01

Issue 6: Behavior when no cache entry exists
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: September 30, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: 1
Section: 2
Rationale/Explanation of issue:

Proposed text:

Section 2. 8th paragraph:

> I also propose adding the following text : If a unicast message is

> received for a destination for which there is no entry in the

> neighbor cache then the message has to be forwarded on all

> segments.

The proposal is also referenced in the following proposed text...

> Section 6 (Effect of changes in spanning tree)

> ----------------------------------------------

> Some of the changes in the topology of the network may result in

> modifications of the spanning tree. Some of these changes are

> addition/removal of a proxy, or addition/deletion of a link on a

> proxy. These changes have some subtle change on the network load.

>

> As soon as a spanning tree change is determined by the proxies in the

> network, they will flush the neighbor cache, and create it afresh. The

> network traffic will increase momentarily, as each proxy will

> broadcast all the packets that it receives. This problem can be

> particularly severe in networks where there is a frequent change in

> the spanning tree.

> There might be some traffic loss, when a new spanning tree is

> constructed.

[Dave Thaler comment]:
Disagree. I believe traffic should be dropped if no cache entry exists.

[Pekka Savola]:

> > The NA is received by P, which then processes it as it would any

> > unicast packet; i.e., it forwards this out interface 1, based on the

> > neighbor cache. However, before actually sending the packet out, it

> > inspects it to determine if the packet being sent is one which

> > requires proxying. Since it is an NA, it updates its neighbor entry

> > for B to be REACHABLE and records the link-layer address b. P then

> > replaces the link-layer address in the TLLA option with its own

> > link- layer address on the outgoing interface, p1. The packet is

> > then sent out interface 1.

==> this doesn't seem to work when moving between segments without a:

1) a cache timeout, or

2) the host, immediately after moving, sending a packet, updating the proxy's cache. If the host is silent before moving and afterwards, there will be no indication where it has gone. Right?

[Chirayu Patel]:

Right. Though, in most cases the host will not be silent (it will get a trigger from L2 about movement), and will attempt to do Router Discovery.

Seamless movement between bridged segments is not supported. We did discuss a solution that involved 1) getting a trigger from L2 that the host has moved, and 2) doing a broadcast of any unicast packet for the moved host on all the proxy ports. This way the unicast packet (NA in this case) would reach the destination. The broadcast would continue till the host sends a packet, and updates the cache.

[Dave Thaler]:

Offhand, I think that's right. If the host always does DAD after moving, for example, then (2) would be the case, with (1) applying otherwise. Both of these are not specific to this spec - indeed essentially the same thing would happen with a classic bridge or switch.

As a result, I don't see anything wrong with the current draft in this regard. It appears to meet the requirement just as well as a classic bridge or switch does.

[Chirayu Patel]:

Neighbor cache entries may be deleted in two scenarios - regular garbage collection, or in case the proxy is reset.
 

ND-proxy has three options in this condition:

1) Flood the packets on all the links till it discovers the link-layer address of the destination. This approach might result in network congestion especially if certain links were carrying heavy traffic when the flooding is initiated.

2) Discard all the packets till the link-layer address is discovered.  This is the most simplistic of the approaches. The ND-proxy does not have to do any extra processing. It hopes that new traffic from the host (whose entry is deleted) will recreate the entry. Most upper layer protocols expect, and can recover from packet loss in the network. However, depending on the time it takes to discover the location of the destination, and the frequency of discarding neighbor cache entries, the situation might be critical. e.g. TCP connections might not be established between two hosts even though they are lying right next to one another. Loss of RTP packets might result in bad VoIP quality at times.

3) Queue the packets towards the destination, and initiate Neighbor Discovery. It seems to be the most safest approach, and is the recommended approach. However, it requires queueing support in the

ND proxy, and it might not always be supported.

The specification should not mandate any option, and all three options should be presented to enable developers to choose the most suitable one.

[Dave Thaler]:

Since the link-layer address is not known, the only way to flood is to use a link-layer broadcast or multicast address.  You couldn't just say "flood", you have to specify how it's mapped since this is not according to the ND spec.  You'd have to (for example) say you're sending it to the solicited node multicast address for the unicast address.  However regardless of the destination address, other undesirable side effects occur at higher layers.  For example, RFC 2463 2.4 (e) says:

    (e) An ICMPv6 error message MUST NOT be sent as a result of

        receiving:

[...]

         (e.2) a packet destined to an IPv6 multicast address (there are

               two exceptions to this rule: (1) the Packet Too Big

               Message - Section 3.2 - to allow Path MTU discovery to

               work for IPv6 multicast, and (2) the Parameter Problem

               Message, Code 2 - Section 3.4 - reporting an unrecognized

               IPv6 option that has the Option Type highest-order two

               bits set to 10), or

         (e.3) a packet sent as a link-layer multicast, (the exception

               from e.2 applies to this case too), or

         (e.4) a packet sent as a link-layer broadcast, (the exception

               from e.2 applies to this case too), or

As a result, normal ICMP errors like port unreachable etc cannot be sent, making this harder to deal with. 

Hence I would prefer to disallow this for three reasons:

1) it's much harder to specify (and implement)

2) it breaks ICMP error handling as noted above

3) it's different from what hosts and routers do when they don't have a link-layer destination address, but the problem is the same

Offhand, I can't think of any problems with the queueing approach though, so have no problem with mentioning the other two options.

Proposed text to add to section 4.1 (Receiving Packets):

"If no cache entry exists (as may happen if the proxy has previously evicted the cache entry or if the proxy is restarted), the proxy SHOULD queue the packet and initiate Neighbor Discovery as if the packet were being locally generated. The proxy MAY instead silently drop the packet. In this case, the entry will eventually be recreated when the sender re-attempts neighbor discovery."

Proposed resolution: Accept text immediately above

Issue 7: Supporting segments with differing MTUs
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: September 30, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: 1
Section: 1.2
Rationale/Explanation of issue:

> 9. Section 1.2 4th bullet.

Current text:

o Support differing MTUs in use on different segments. That is, all segments on a bridged link must use the smallest MTU of any segment. Note that the result of this is that in the absence of cooperation of the network administrator (who can configure routers with a smaller MTU to advertise in Router Advertisements) a bridge-like IPv6 proxy can only connect links with equal MTU, or where all routers are on segments with the smallest MTU.
 

Proposal:

> Rephrase to:

> Transparently support different MTU's in use on different segments.

>

> The rest of the text should be moved in another section:

Section 7.1) (MTU configuration)

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

If the proxies within the subnet support different link MTU's, then the nodes within the subnet should be configured with the smallest link MTU amongst all the link MTU's. Thus, deployment of the proxies might not be a simple "plug and play" operation.

Misconfiguration of the MTU in the nodes will result in blackholes that may prove difficult to track.

[Dave Thaler comment]:

Need to be careful here since one of the two primary scenarios is where PPP is the upsteam link. Here the upstream link will probably have MTU=1280 and the downstream link 1500. This can be made to work by the proxy making sure there's a MTU=1280 option in the RAs it proxies. However it can only work in limited scenarios not in general. The existing text sort of implied this with "... where all routers are on segments with the smallest MTU", but it should be clarified.

Proposed text to add to behavior section:

IPv6 Router Advertisements

To support scenario 2, if the MTU of the upstream segment is smaller than the MTU of the downstream segment then IPv6 Router Advertisements (RAs) must also be proxied as follows.  If the RA contains an MTU Option, the RA is forwarded unmodified.  Otherwise, the proxy adds an MTU Option with a value of the link MTU of the segment on which the RA was received, and then proxies it as described above.

[Dave Thaler]: This issue is obsoleted by Issue 13.

Proposed resolution: Accept

Issue 8: Make Informational not StdsTrack
Submitter: Brian Carpenter
Submitter email address:
Date first submitted: July 16, 2003
Reference:
Document: NDProxy-00, WG Charter
Comment type: Technical
Priority: S
Section: Header
Rationale/Explanation of issue:

Dave Thaler wrote:

>

> Brian Carpenter writes:

> > I'd go a bit further. I messed around with a large bridged network

> > for some years, and this included messing with ARP proxies and all

> > the troubles they cause. Basically, making a level 2 device simulate

> > level 3 functions is a kludge, and it gets even worse when

> > attempting to "bridge" different LAN technologies. It probably has

> > some failure modes that are very hard to analyze.

> >

> > So while I understand there may be a market for such devices, I

> > would have very low confidence in our ability to publish a

> > watertight spec. An informational document would seem the right way

> > to go, rather than anything that looks like a standard.

>

> Currently the IPv6 charter has a goal:

> Jul 03 Submit Proxy RA to IESG for Proposed Standard.

>

> While I have no problem with Informational if we do publish the

> approach, the WG should decide whether it wants to either change the

> charter, or go with a different approach for PS. It sounds like you

> (Brian) are arguing for the former.

I don't know that there is any other approach except to say "install a router". I hadn't really though about this before yesterday, when you reminded me of issues I was handling operationally more than ten years ago. So yes, I'm arguing for publishing off the standards track (which is either a charter update or an IESG decision, I guess).

Brian

Proposed resolution: Accept, and get AD approval
See also: Issue 19 (Make Experimental)

Issue 9: Structure of neighbor cache
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: September 30, 2003
Reference:
Document: NDProxy-00
Comment type: Technical
Priority: S
Section: Header
Rationale/Explanation of issue:

Should we specify the structure of the IPv4 neighbor cache on an ARP proxy?

Should we specify the structure of the IPv6 neighbor cache on an ND proxy differently from what is in RFC 2461?

Chirayu proposed:

Each entry of the neighbor cache contains

• IP (IPv4, or IPv6) address

• port number

• link-layer address

The entry is created by recording the IP address of the sender, the port number on which it was received, and the link-layer address of the sender.

A new entry is created in the link-table whenever a new (not present in the neighbor cache) sender IP address encountered in any packet. A keep alive timer is also started. This timer is restarted whenever any packet with the same source IP address is encountered. On expiry of the timer, the entry is deleted.

The entry is updated in two circumstances

• A packet with the IP address, as the one in the entry, is received on another port. In this case the port number is modified.

• A packet with the IP address, as the one in the entry, is received on with a different source link-layer address. In this case the link-layer address is modified.

An entry is deleted when

• Expiry of the keep alive timer.

• Change in the spanning tree. Any change in the spanning tree may result in change of port numbers for few entries.  Since it is not possible to determine the affected entries, and to minimize traffic loss, the complete table is flushed, and created afresh.

The neighbor cache structure is generic enough to be used along with both IPv4, and IPv6 addresses.

Proposed rejecting this at Minneapolis IETF, and just assume than an NDProxy is an "IPv6 Node" meeting all the requirements for IPv6 nodes.  No objections.

The rationale is that with the status going to Informational rather than Proposed Standard, we just need to describe things in the easiest to understand way.

[CP proposed alternate text]:

The neighbor cache is maintained by the ND proxy as specified in RFC2461.

The neighbor cache (combined or multiple tables) for all the interfaces of the ND proxy should not have a duplicate entry.

All messages that are not destined for the ND proxy, but are meant to be proxied will result in the creation of an entry in STALE state if there is no pre-existing entry.

As per RFC 2461, if the ND proxy receives a NS, RS, RA, or Redirect, and there is no entry in the state table, an entry will be created in the STALE state. For ND proxies, an entry in STALE state is created for *any* packet (including NS, RS, RA or Redirect) packets. This change will allow the ND proxy to populate its neighbor cache after it was reset.

All other processing shall be done as specified in RFC 2461.

[DT actions]:

Add to section 2 (Terminology):

"Finally, while it is possible that functionality equivalent to that described herein may be achieved by nodes which do not fulfill all the requirements in [NODEREQ], in the remainder of this document we will describe behavior in terms of an IPv6 node as defined in that document."

Add to section 4.1 (Receiving Packets):

"When a packet from any IP source address other than the unspecified address is received on a proxy interface, the neighbor cache of that interface
SHOULD be consulted to find an entry for the source IP address. If no entry exists, one is created in the STALE state."

Resolution: Accept clarifying text above

Issue 10: Remove IPv4 Support
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: November 11, 2003
Reference:
Document: NDProxy-01
Comment type: Technical
Priority: S
Section: Multiple
Rationale/Explanation of issue:

[Pekka Savola]:

[Chirayu Patel]:

[Pekka Savola]:

[Chirayu Patel]:

Will have to think about this one. Do you have any alternate approaches in mind?

Proposed resolution: Discuss

Issue 11: Say when bridging is sufficient
Submitter: Pekka Savola
Submitter email address: pekkas@netcore.fi
Date first submitted: November 11, 2003
Reference:
Document: NDProxy-01
Comment type: Editorial
Priority: 2
Section: Introduction
Rationale/Explanation of issue:

The point is that NDproxies in these cases can be often replaced by normal, bridging devices.

However, the user probably wants to do stuff like firewalling on the box as well.. which was the reason to at least include this case in the introduction, even if ND-proxies are not necessarily a requirement.

...
[If] the ISP <-> user link is also Ethernet, ND-proxy is not required. I.e., summarize the few scenarios where bridging would also be useful and could be used instead of a NAT box.

[DT comment]:

In my opinion, it is outside the scope of this document to discuss scenarios for other solutions.  The purpose of this document is to cover the two scenarios for NDproxy.

The Introduction already says that bridging should be used except where it can't work, and enumerates the two cases where it doesn't.  Hence, every scenario which has neither limitation is a bridging scenario.

Proposed resolution: Reject

Issue 12: AH removal
Submitter: Pekka Savola
Submitter email address: pekkas@netcore.fi
Date first submitted: November 11, 2003
Reference:
Document: NDProxy-01
Comment type: Technical
Priority: 1
Section: Introduction
Rationale/Explanation of issue:

Proposed resolution: Accept

Issue 13: MTU Clarifications
Submitter: Chirayu Patel
Submitter email address: chirayu@chirayu.org
Date first submitted: November 25, 2003
Reference:
Document: NDProxy-01
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

The present approach to insert an MTU option has one more pitfall than the one considered (misconfigured router) in the I-D.

1. If the path from the router to the host has multiple proxies then

    a) even if one proxy inserts an MTU option, the value might not be correct, and the leaf proxy (the proxy connecting to the node) will not be able to rectify it.

    b) changes in the path from the router to the host might result in a path that requires a smaller MTU value than the one sent in the RA.

Since ND proxies can be used in unmanaged networks, where changes in router configuration are not to expected, I think a better approach to solve the problem would be to allow the ND proxy to generate ICMPv6 "packet too big" messages to facilitate PMTU.

It seems that the I-D could do with some clarification. On one hand we state that support segments with different MTU is a non-requirement, and on the other hand we present a solution.

There seem to be four possible solutions.

1. Configure the Router so that the RA carries the correct (minimum) MTU value.

2. Invent an "MTU discovery" protocol.

3. ND proxy to include an MTU option in the RA.

4. ND proxy to send out ICMPv6 "packet too big".

Solution 1 will always work but it is not practical. Customers cannot be expected to configure the routers on their home networks. Also, it will not allow nodes to use larger MTU's even where it is possible.

Solution 2 is yet to be devised, and seems to be an overkill for solving this problem.

Solution 3 is a partial solution, and will also require router configuration (so that MTU option is not embedded in the RA).

Solution 4 works without configuration. The downside is that it seems to be an hack. However, the same can be argued about solution 3.

FYI, I went through RFC 1981 (Path MTU Discovery for IPv6), and this is what section 3 has to say:

Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself. In a situation such as when a neighboring router acts as proxy [ND] for some destination, the destination can to appear to be directly connected but is in fact more than one hop away.

It seems that the authors had envisaged that ND proxies would send an out an ICMPv6 "packet too big" message.... All said, before we jump into the solution space, the first step is to agree on the requirements. IMHO, we should convert the non-requirement into a requirement.

[DT comment]:

Originally I thought that generating "packet too big" messages was illegal since the proxy does not appear as a hop in the path (since it doesn't decrement the hop limit).

However, RFC 2461 section 4.6.4 does mention the possibility (emphasis added):

In configurations in which heterogeneous technologies are bridged together, the maximum supported MTU may differ from one segment to another. If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers use the MTU option to specify the maximum MTU value that is supported by all segments.

Hence, I now agree this is a better and simpler approach.

[DT actions]:

1) Removed non-requirement that appeared to conflicted with scenario 2 (PPP upstream).

2) Removed subsection on adding MTU option to RAs in scenario 2 since RAs can now be simply forwarded.
3) Added subsection entitled "Sending Packet Too Big Messages":

Whenever any packet is to be forwarded out an interface whose MTU is smaller than the size of the packet, the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6].

Proposed resolution: Accept

Issue 14: Add examples to protocol guidelines
Submitter: Pekka Savola
Submitter email address: pekkas@netcore.fi
Date first submitted: November 11, 2003
Reference:
Document: NDProxy-01
Comment type: Editorial
Priority: 1
Section: 7 (Guidelines to proxy developers)
Rationale/Explanation of issue:

> > ==> Could you spell out, for clarity, some protocols:

> > a) which are not supported by this spec, or

> > b) which do not need to be supported by this spec (but one could think whether they need be), e.g. DHCPv6?

>

> DHCPv6 is supposed to be supported. We did discuss it. :-) All other

> protocols that are not mentioned are not supported. The document has a

> guideline section (section 7) to help implementors in supporting other

> protocols.

Yep, the point was to just add examples of already supported protocols (without modifications, e.g. DHCPv6 because DHCPv4 requires special stuff), and protocols which are *NOT* supported, but could be, with extensions.

[DT actions]:

After "If the link-layer address in the payload of the protocol will never be used in any link-layer header, then the proxy should not substitute it with its own address."

Added "No special actions are required for supporting these protocols. For example, [DHCPv6] is in this category."

Proposed resolution: Accept

Issue 15: Clarify relationship to Prefix Delegation
Submitter: Ralph Droms
Submitter email address: rdroms@cisco.com
Date first submitted: March 23, 2004
Reference:
Document: NDProxy-02
Comment type: Editorial
Priority: 1
Section: 1 (Introduction)
Rationale/Explanation of issue:

I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be time to revisit the need for ND proxies.

It seems the primary motivation for ND proxies is to avoid the need for L3 devices that require configuration, prefix assignment and configuration. I read the two scenarios in section 1, and, more generally, the motivation for ND proxies to provide bridging between links with dissimilar technologies, as motivation for the use of one ND proxy between a single upstream link (perhaps to a service provider) and one or more local networks.

In the case of a more complicated local topology, it seems to me that it would be highly unusual to find dissimilar link technologies that require the use of ND proxies. Why would anything but bridgeable IEEE802 be used among the local networks?

We've done the hard engineering work in specifying DHCPv6 to solve the problem of configuration and prefix delegation for a single gateway device that has an upstream PPP, cable or wireless connection and multiple downstream local networks. DHCPv6 PD is a published standard with multiple, interoperable implementations. It is available in simple home gateways, equivalent to the IPv4 NAT device in my basement. I don't see a compelling requirement to invent something new.

[Erik Nordmark]:

First of all, based on RFC 3177 an ISP needs to be capable of handing of /48 prefixes to customers. The issue here is when the ISP doesn't do that.

[Pekka Savola]:

Note that the ND-proxy case is rather strong in 3GPP environments as well: the nodes are given a /64 per PDP context. If you want to hook up your laptop to your mobile (which has v6 PDP context), the mobile either has to do ND proxying, or you'll have to open a new PDP context on your laptop (e.g., of PPP type). And those 3GPP guys always start screaming when you want to open more PDP contexts.. :)

[Erik Nordmark]:

The basis for needing ndproxy in this case is that the ISP doesn't want to explicitly delegate a prefix to their customer. I see two possible reasons for this behavior (and there might be more)
- the ISP wants to provide tiered services with a single device service at the bottom i.e. only allow one host/IPv6 address
- it is too hard for them to explicitly delegate prefixes

[Pekka Savola]:

Note that this is not a binary decision, i.e., the ISP might decide that "OK, it's not too hard for us to delegate the prefixes, but if we do that, we want some extra payment from the user for the trouble".  In that kind of environment, ensuring that the users have tools to cope with a /64 prefix as well would seem to be really important.

For these two basic cases, I think ND-proxy would be applicable in 1.b) (of my own proposition, above) and 2).

[DT proposed text]:

We also note that Prefix Delegation [PD] could also be used to solve this scenario. There are, however, two disadvantages to this.  First, if an implementation already support IPv4 ARP proxying (which is indeed supported in a number of implementations today), then IPv6 Prefix Delegation would result in separate IPv6 subnets on either side of the device, while a single IPv4 subnet would span both segments. This topological discrepancy can complicate applications and protocols which use the concept of a local subnet. Secondly, the extent to which Prefix Delegation is supported, and supported without additional charge, is up to the service provider. Hence, there is no guarantee that Prefix Delegation will work without explicit configuration or additional charge. Bridging, on the other hand, allows the device to work regardless of the service provider's policies, just as a NAT does. Hence bridging avoids the incentive to NAT IPv6 just to avoid paying for another prefix.
 

Proposed resolution: Accept