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

["Velt, R. (Ronald) in 't" <Ronald.intVelt at tno.nl>]

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