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

From: "Dave Thaler" <[email-masked]>
Date: Thu, 20 Oct 2005 18:41:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:int-area-
> [email-masked]] On Behalf Of James Kempf
> Sent: Thursday, September 15, 2005 3:47 PM
> To: [email-masked]; Thomas Narten
> Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt
> 
> Thomas,
> 
> I share your concerns about this draft. At a minimum, pulling the IPv4
> specification out of the draft seems appropriate.

This was Issue #10 on the old NDProxy Issues list:
http://www.icir.org/dthaler/NDProxyOldIssues.htm#Issue%2010

The resolution of that issue was previously:
> [IETF 59 minutes]:
> Options include: 
> 1) leave IPv4 in with caveat; 
> 2) remove all mention of IPv4; and 
> 3) put IPv4 support in an appendix.  
> After some discussion, the chairs polled the room.  Approximately 8
people 
> felt we should remove IPv4 support, and approximately 4 people felt we

> should keep it in.  Thomas Narten observed that it was disappointing
that 
> there were so few opinions in the room.  The chairs noted that since
the
> working group didn't have a strong opinion, we should defer to the
author.
>
> [DT comment]:
> So far the authors have chosen the path of least author work (i.e., 
> no change).

Since there seems to still be vocal support for removing IPv4, and no
vocal support for keeping it, and the poll at IETF59 also had more
in favor of removing, I have removed the IPv4 portions from draft-04
as suggested.

> My particular concern, though, is with the lack of support for
security.
> When SEND was finalized, we had some very vague ideas about how to do
> proxy
> ND security which didn't seem ready for standardization. Now, after
about
> a
> year and a half of discussion in IRTF/MOBOPTS, I think we are
beginning to
> have some firmer ideas about how SEND could be extended to proxy ND.
If
> the
> WG decides that it would like to continue working on this and decides
that
> security is important, we could bring some of the IRTF/MOBOPTS work
into
> IETF.

Jari Arkko submitted proposed replacement text for the security 
considerations section which summarizes the above, and the text 
has been incorporated.

>             jak
> 
> ----- 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

Removed as recommended.

> > 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.

Updated security considerations section with text from Jari Arkko.

> > 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.

Removed IPv4 material, so this point goes away.

> > 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.

Removed IPv4 material from this document.

> > 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

Proposed updated draft is at
http://www.icir.org/dthaler/draft-ietf-ipv6-ndproxy-04.txt

Thanks,
-Dave

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