Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model

["Holtzer, A.C.G. (Arjen)" <arjen.holtzer at tno.nl>]

Hi Ulrich, Ronald, Alex,

Actually, to be more specific, I agree with the text in draft-bernardos-autoconf-addressing-model-01 which states in section 3.2:

"The use of /32 (in the IPv4 case) or /128 (in the IPv6 case)
   prefix lengths can be an effective way to ensure that prefixes are
   non-overlapping.  However, it would be needlessly restrictive to
   mandate the use of only these prefix lengths."

As far as section 4.2 of draft-clausen-manet-autoconf-recommendations-00 is concerned: this addresses the issue with ICMP redirect messages when the addresses of the nodes in the "hidden-terminal"-scenario of Figure 9 are using the same subnet prefix. I agree this is an issue and it can be solved by using non-overlapping prefixes, not exclusively by using /32 IPv4 and /128 IPv6 prefixes. This seems unnecessarily restrictive to me.

And about my opinion on the WG document: I think draft-ietf-autoconf-adhoc-addr-model is a good point for continuation, but I think Ronald has several good points. In general, I am, like everyone in the WG, in favour of fast progress with the addressing model, since I am waiting for the moment to go into solution space.

Best regards,
Arjen

 

> -----Original Message-----
> From: Ulrich Herberg [mailto:ulrich at herberg.name] 
> Sent: donderdag 29 oktober 2009 13:14
> To: Holtzer, A.C.G. (Arjen)
> Cc: Velt, R. (Ronald) in 't; autoconf at ietf.org
> Subject: Re: [Autoconf] On WG progress 
> anddraft-ietf-autoconf-adhoc-addr-model
> 
> Arjen, Ronald,
> 
> I hope that Ronald did not really ask you to say "me too" but 
> rather to state your own opinion on the list (whether that be "pro" or
> "against") :-)
> 
> Please read draft-clausen-manet-autoconf-recommendations-00 
> if you did not yet. This explains the rationale for using /32 
> and /128 prefixes.
> It also explains what can go wrong when using shorter 
> prefixes and the symptoms thereof (ICMP redirects...)
> 
> Ulrich
> 
> 
> On Thu, Oct 29, 2009 at 11:59 AM, Holtzer, A.C.G. (Arjen) 
> <arjen.holtzer at tno.nl> wrote:
> > Hi all,
> >
> > Ronald told me to say: "Me too". :)
> >
> > Regards,
> > Arjen
> >
> >
> > ________________________________
> > From: autoconf-bounces at ietf.org 
> [mailto:autoconf-bounces at ietf.org] On 
> > Behalf Of Velt, R. (Ronald) in 't
> > Sent: donderdag 29 oktober 2009 11:57
> > To: Thomas Heide Clausen; autoconf at ietf.org
> > Subject: Re: [Autoconf] On WG progress 
> > anddraft-ietf-autoconf-adhoc-addr-model
> >
> > Thomas, Ryuji, WG members,
> >
> > My vote below:
> >
> > ________________________________
> > From: autoconf-bounces at ietf.org 
> [mailto:autoconf-bounces at ietf.org] On 
> > Behalf Of Thomas Heide Clausen
> > Sent: donderdag 22 oktober 2009 1:50
> > To: autoconf at ietf.org
> > Subject: [Autoconf] On WG progress and 
> > draft-ietf-autoconf-adhoc-addr-model
> >
> > All,
> > It appeared to the chairs that the comments raised at the Stockholm 
> > IETF, as well as on the list subsequently, concerning the document:
> > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model
> > had been addressed fully by the editors, and to the WGs 
> satisfaction - 
> > at least, there were no issue raised to the latter/latest version 
> > hereof. The chairs therefore found it a good idea to move 
> the document 
> > forward as a WG document, and progress this document as such. We 
> > therefore approved for
> > publication:
> > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model
> > We (the chairs)  still believe that this is the proper approach in 
> > order to make progress for the WG.
> > Do note that the WG is 7 months past the milestone for initial 
> > document submission, and 1 month past the milestone for having 
> > progressed the document to the IESG and/or closed up shop!  
> And, there 
> > has been no discussions (in meetings or on this list) on 
> alternative 
> > candidate documents for the work item which [autoconf] is 
> chartered to accomplish.
> > To put it bluntly, this WG is far far behind schedule and this 
> > document seemed, and still seems, by virtue of having been widely 
> > discussed and agreed upon, as the best shot at making 
> progress for this WG.
> > That said, we (and, this we is also the chairs) will take this 
> > opportunity to ask the WGs opinion on how to progress. If 
> you have any 
> > opinion, please let it be known to the WG (via this mailing list) 
> > before 29/10/09 (i.e. Thursday next week) at noon CET. Please be 
> > specific and constructive, i.e., pick one of:
> > o if you think that the WG should proceed with 
> > draft-ietf-autoconf-adhoc-addr-model
> > as a baseline, say so!
> > o if you think there're cardinal (but fixable) issues 
> missing or wrong 
> > with draft-ietf-autoconf-adhoc-addr-model, then let the WG 
> know what 
> > these issues are, and propose a solution before the deadline. The 
> > Editors will certainly do their best to address the issues.
> >
> > Yes, I think there are serious, but fixable issues with 
> > draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote 
> > draft-bernardos-autoconf-addressing-model to offer a different 
> > perspective on these issues. Let me briefly summarize here 
> our (or at 
> > least: my) main
> > objections:
> >
> > 1.  Section 1, Introduction and section 3, Applicability Statement: 
> > Nowhere in these sections is there any mention of the assumed 
> > host/router model, i.e. whether applications (including management 
> > clients) can run on routers and if they can, make use of the 
> > interfaces / addresses that are the subject of this draft 
> OR whether 
> > applications are assumed to always separated by at least 
> one hop from 
> > these interfaces. However, the ghost of 
> > draft-clausen-manet-autoconf-recommendations-00 seems to be 
> hovering 
> > over this draft, so the latter is sort of implied. I would 
> prefer that 
> > this is spelled out, as it impacts the type of addresses 
> that need to be configured, I might not necessarily agree, 
> but al least it would be clearer.
> >
> > 2. Section 4, IP Subnet Prefix Configuration:
> >
> > - "Subnet prefix configuration on such interfaces must thus 
> not make 
> > any promises in terms of direct (one hop) IP connectivity to IP 
> > addresses other than that of the interface itself." I find this 
> > unconvincing. What promise would there be, really? Imagine a wired 
> > Ethernet, with several nodes on it sharing a prefix.It 
> would be rare 
> > for the subnet to be fully populated, even on an IPv4 /24. So if I 
> > dream up a host part / Interface ID, append it to the subnet prefix 
> > and use that as a destination address, what would be my chances of 
> > reaching another node? To be clear, I *agree* on the unique / 
> > non-overlapping subnet prefix principle stated here, but 
> find the motivation lacking.
> > - It should say "non-overlapping", because "not the same" 
> is not sufficient.
> >
> > 3. Section 6, Addressing Model
> >
> > - 6.1, IPv4 Model: Disagree that the prefix length should 
> be /32. For 
> > subnet prefixes to be unique / non-overlapping (see definition in 
> > draft-bernardos-autoconf-addressing-model), is a necessary, 
> but also 
> > sufficient condition. I ran a MANET with 192.168.x.1/24 on 
> the MANET 
> > interfaces for many months. I fail to see what's wrong with that. 
> > (Agree on what is said here about IPv LL's, by the way)
> >
> > - 6.2, IPv6 Model: Strongly disagree that the prefix length 
> should be /128.
> > Why paint ourselves into a corner like that? I would urge the draft 
> > authors to have a look at RFC 5375, "IPv6 Unicast Address 
> Assignment 
> > Considerations". While this is "only" an informational RFC, 
> I think it 
> > is worth reading. When in a hurry, you can skip Appendix A, 
> but do not 
> > skip Appendix B! Besides, there was discussion at the 
> IETF-75 Autoconf 
> > session, see the minutes of that meeting:
> >
> > Dave Thaler
> > - Consistency with RFC 4291 (in particular section 2.5.1).
> > - Do you believe you have 64-bit interface identifiers that
> >   are unique within the subnet prefix? (the 64-bit part being
> >   a requirement for all unicast addresses that do not begin
> >               with binary '000').
> > - If the answer to previous question is 'no', do you require
> >   prefixes to start with binary '000'?
> > - If that is not the case either, shouldn't the document say
> >   that the addressing model will not be compliant with RFC4291?
> >
> > and:
> >
> > Dave Thaler
> > - If you believe that you ARE compliant with RFC4291, the way to
> >   phrase it is, that you have a /64 subnet prefix, but it is only
> >   assigned to a single host.
> > and later Thomas Narten wrote:
> >
> > Thomas Narten (Jabber)
> > - IMO, /128 does not conflict with existing specs. We are 
> blurring and 
> > confusing
> >   various issues. You can have a /128 for on-link prefixes 
> and still 
> > have a
> >   64-bit Interface IDs.
> >
> > but he did not explain this any further. So who is right: 
> Thaler or Narten?
> > And what ithe prefix length of a ULA assigned to an 
> interface? /64 as 
> > far as I was able to figure out.
> >
> > - IPv6 link-locals: (Too?) Much has been said about this already. My
> > opinion: LL's are there, and they may be pretty hard to get rid of. 
> > I'm more concerned about existing platforms than about these new 
> > ultra-resource-starved devices that have been subject of 
> discusion on 
> > the ML recently. You can choose to not use them for routing 
> purposes 
> > (in the narrow definition of routing as discovering network 
> topology 
> > and populating the RIB / FIB), but you may not be able to influence 
> > whether they are used for forwarding. I've seen neighbor 
> solicitations 
> > being sent with LL source addresses from MANET interfaces, 
> that also 
> > had global IPv6 addresses configured.
> >
> > - 3rd bullet under "known limitations": routing protocol 
> packets are 
> > sent hop-by-hop. They are intercepted. processed and possibly 
> > regenerated at each router, so limitation does not apply.
> >
> > Oops, getting too close to deadline. This will have to do.
> >
> > Regards,
> > Ronald
> >
> >
> >
> > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond 
> > hope, let the WG know explicitly how you suggest that we 
> progress  at 
> > this point
> > --
> >   considering the current timeline!!
> > Cheers,
> > Ryuji & Thomas
> >
> > This e-mail and its contents are subject to the DISCLAIMER at 
> > http://www.tno.nl/disclaimer/email.html
> >
> > This e-mail and its contents are subject to the DISCLAIMER at 
> > http://www.tno.nl/disclaimer/email.html
> >
> > _______________________________________________
> > Autoconf mailing list
> > Autoconf at ietf.org
> > https://www.ietf.org/mailman/listinfo/autoconf
> >
> >
> 
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html