Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 16 Sep 2005 12:31:39 -0400

Hi Thomas, 

I share and agree with all of the concerns you've listed
below. Let me also make a couple of side notes:

- Making an RFC experimental/informational does not limit anyone from
implementing it. This is a proven fact (e.g. 3314, 3316 and others). 

- Following the above point, I think experimental RFCs
  should be scrutinzed as if they were going on standards
  track.

On the other hand of the argument, I also think the features
in the draft can be useful in a couple of cases. In particular,
I see them useful for the mobile phone example that Bob mentioned. 
I think they are also useful for some nested nemo cases but at some
point, scalability might become an issue. For instance, consider
a scenario where a bus/train is offering connectivity to passengers. 
A passenger might come on the train with a nemo (e.g. PAN) with
a mobile router and one or more devices attached to it. The MR would
connect the other devices to the train's router, which in turn
connects them to the Internet. ND-proxy would allow the train's
MR to get a /64 (e.g. following the recommendation of RFC 3314, 
which was adopted by 3GPP) and proxies it to lower MRs and so on.

So, I see the need in some cases but I suspect that this is 
only a subset of the overall use cases of the current draft.

Perhaps one way forward would be to limit the applicability of 
the draft by at least spelling out any scalability limitations. 

Of course there is still the SEND comment, which I think we 
should take seriously. In theory, this can be a temporary situation
which will eventually be rectified but I'm doubtful about that
because I think the way to solve this will be quite complex
and unlikely to be implemented by the devices I mentioned above.

Hesham

 > ----- Original Message ----- 
 > From: "Thomas Narten" <[email-masked]>
 > To: <[email-masked]>
 > Sent: Thursday, September 15, 2005 8:44 AM
 > Subject: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt
 > 
 > 
 > > I'm sending this to the int-area because the concerns I have are
 > > broader than the just the ipv6 WG. This document is really about
 > > bridging/proxy arp in general, and it does not restrict itself to
 > > IPv6; it also covers IPv4.
 > >
 > > I've read this document a couple of times (it is on the 
 > IESG's plate
 > > to review), but have general concerns. I wonder if others in the
 > > community share my concern.
 > >
 > > The bottom line is that I think the IPv6 portion of 
 > document/protocol
 > > is both under-specified and too broad in scope and I worry 
 > that there
 > > are a lot of potential gotchas lurking. I also worry that it will
 > > break some of our standards track protocols. And if it gets widely
 > > implemented, we'll have to deal with the resultant mess. We have
 > > plenty of experience in IPv4 with proxy arp, and some of 
 > it has been
 > > unpleasant.
 > >
 > > I have the following meta concerns:
 > >
 > > 1) I do not believe the material on IPv4 ARP proxy should be
 > > included. It is not in-scope for the IPv6 WG to be 
 > developing it, and
 > > any document on proxy ARP in IPv4 really requires review from the
 > > broader community. AFAIK, that review has not taken place.
 > >
 > > Recommendation: remove the IPv4 material and place in a separate
 > > document
 > >
 > > 2) This document breaks SEND (but does not say this 
 > clearly). I have
 > > doubts that we should be publishing documents that break 
 > our standards
 > > track protocols (especially ones that we believe are 
 > important). Or at
 > > the very least, if it is published, very strong wording is 
 > needed to
 > > point out that it is incompatable with SEND, e.g., an IESG note.
 > >
 > > 3) this document may have implications for DHC. In particular,
 > > document says:
 > >
 > > One limitation of this rule is that if the authentication
 > > protocol for DHCPv4 described in [DHCPAUTH] is used, only
 > > clients that set the BROADCAST flag themselves will be able to
 > > use DHCPv4 through the proxy.
 > >
 > > If this document breaks some forms of DHC, that needs to 
 > be noted up
 > > front and more visibly. I also think more discussion would be
 > > appropriat here, to be sure we fully understand the issue here.
 > > Again, I'm also not sure we should be promoting documents 
 > that cause
 > > problems for existing standards track protocols.
 > >
 > > 4) The history of this document is troubling, and I believe it does
 > > not have strong support from the WG. Rather, I'd 
 > characterize this as
 > > an effort that has gotten this far mostly because the vast 
 > majority of
 > > the WG has tuned out and no longer is following the work.
 > >
 > > The history of this effort (though I may be biased) is 
 > that the IPv6
 > > WG desired a simple proxy mechanism for the following case. Suppose
 > > one has an access router connecting to an upstream ISP, 
 > and that link
 > > is assigned a prefix (say X). It would be nice if the access router
 > > could readvertise that prefix (say for a home network), acting as a
 > > simple bridge. That way the end site wouldn't need a 
 > separate prefix
 > > (say if the ISP as stingy and didn't want to give it out). I had
 > > always assumed this configuration was a simple star 
 > topology with the
 > > access router at the center.  Indeed, the current IPv6 
 > charter says:
 > >
 > >> - Develop Proxy Neighbor Discovery solution for prefix delegation
 > >>   and publish. This enables a simple site border router to
 > >>   re-advertise downstream a prefix it hears on its upstream link.
 > >
 > > The WG had such an item in its charter for a long time (years), but
 > > from what I can tell, there was limited interest in terms 
 > of actually
 > > doing the work, so it languished. What "the WG" finally 
 > produced was
 > > the above document. But it's scope is quite a lot broader than what
 > > the charter called for. And, I think its fair to say that the work
 > > reflects a small number of contributers (with good intentions) but
 > > apathy and almost no help from the rest of the WG (e.g., 
 > the last WG
 > > LC received no comments). So, this document is going through the
 > > process by default, rather than being a strongly reviewed piece of
 > > work.
 > >
 > > Margaret (as AD) raised a similar point about the scope of 
 > this work
 > > in the WG a few months back.  For details, review the discussion
 > > during the WG last call in May: (sorry, I can't find a a 
 > good URL to
 > > point to -- sigh). There was hardly strong support for the 
 > document,
 > > and in fact, the reviews were negative and the document 
 > was taken off
 > > standards track and put on experimental in response to that thread.
 > >
 > > In summary, I believe  there are good reasons why the 
 > document in its
 > > current form should not be published with an IETF blessing.
 > >
 > > Some possible options:
 > >
 > > 1) Drop the work completely. This may not be as silly as 
 > it seems. A
 > >   basic premise of this work is that its somehow not 
 > possible (or too
 > >   hard) to get a proper prefix delegated from an ISP. 
 > However, there
 > >   is little evidence that this will be a real issue in 
 > IPv6. Current
 > >   RIR address allocation polcies and existing ISP practices is to
 > >   give out chunks of address space (rather than /64s), or a single
 > >   address.
 > >
 > > 2) Move all the IPv4 material to a separate document (this 
 > should be
 > >   done in any case if work on this continues). Also, the IPv4
 > >   material would need serious  review from the IPv4 community.
 > >
 > > 3) Pull out all the more general bridging stuff for the 
 > IPv6 case and
 > >   just solve the narrow problem described earlier, namely a single
 > >   router acting as a star/hub for proxying.
 > >
 > > 4) Add an IESG note with a warning that this has potential 
 > issues and
 > >   the IETF doesn't recommend widespread adoption/use. (Indeed, the
 > >   current applicability statement is really weak and gives
 > >   insufficient guidance in terms of where this technology 
 > can safely
 > >   be used)
 > >
 > > And what I'd _really_ like to see, more than anything 
 > else, is strong
 > > support from the community both for scope of this document and the
 > > details of what are contained in the document. In the 
 > absence of that,
 > > if the document is published, I'd like to see a strong 
 > note adequately
 > > characterizing the issues above.
 > >
 > > Thomas
 > >
 > > _______________________________________________
 > > Int-area mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/int-area
 > > 
 > 
 > 
 > 
 > _______________________________________________
 > Int-area mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/int-area
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 20 Sep 2005 08:47:54 -0400

I support nd proxy it should be PS.  It should not go to DS without wide
implementation from multiple members I do not believe it is under
specified either.  Would I recommend it on a production network, not at
all.  What some may be uncomfortable with if they are not implementers
is the complexity for net centric implementation capabability.  The idea
has been implemented in many forms and has nothing to do with ARP or ND,
they are simply the vehicle to permit the deployment model of
partitioned links.  This team did its job and checked with multiple
domain experts across the IETF my input is to move on.

/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E 
> Carpenter
> Sent: Monday, September 19, 2005 8:47 AM
> To: Pekka Savola
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt
> 
> People might want to look in the tracker at the other comments
> that have come up.
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=12623&rfc_flag=0
> 
>      Brian
> 
> Pekka Savola wrote:
> > (FWIW, I think ND proxies are useful and needed.)  Some comments 
> > inline.  Adding ipv6 WG.
> > 
> > On Thu, 15 Sep 2005, Thomas Narten wrote:
> > 
> > v4 part is said to reflect what one implementation does, 
> but I guess 
> > even for Informational, that info might be too much.  I 
> guess it could 
> > be taken out of fleshed out in a separate spec (if anyone 
> is interested 
> > in documenting proxy-arp behaviour..)
> > 
> > Wording could be enhanced, but I do not think this document 
> should be 
> > blocked by the missing SEND details.
> > 
> > This is moot if v4 parts are removed.
> > 
> >> simple bridge.
> > ...
> >> But it's scope is quite a lot broader than what
> >> the charter called for.
> > 
> > 
> > I'm not sure if I understand your comment.  Are you saying 
> the ND proxy 
> > spec is too complicated?
> > 
> > Well, I myself suggested removing the spanning tree loop 
> prevention from 
> > the draft completely (now it has a bit in the RAs) because 
> it wasn't 
> > needed in the applicability we had in mind.  But folks that 
> didn't like 
> > ND proxy argued that infinite loops are not nice, even in illegal 
> > configurations, so we're stuck with some additional specification.
> > 
> > How would you like to see it simplified?  Do you have an 
> alternative in 
> > mind?
> > 
> > (To me, ND proxies seems "as simple as it can get" excluding loop 
> > prevention which I argued for removal but folks thought the failure 
> > modes were too dangerous..)
> > 
> 
>