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
