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

[Ulrich Herberg <[e-mail]>]

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)
<[e-mail]> wrote:
> Hi all,
>
> Ronald told me to say: "Me too". :)
>
> Regards,
> Arjen
>
>
> ________________________________
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Velt, R. (Ronald) in 't
> Sent: donderdag 29 oktober 2009 11:57
> To: Thomas Heide Clausen; [e-mail]
> Subject: Re: [Autoconf] On WG progress
> anddraft-ietf-autoconf-adhoc-addr-model
>
> Thomas, Ryuji, WG members,
>
> My vote below:
>
> ________________________________
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Thomas Heide Clausen
> Sent: donderdag 22 oktober 2009 1:50
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf
>
>