Thomas, Ryuji, WG members,
My vote below:
All,
It appeared to the chairs that the comments raised at the Stockholm
IETF, as well as on the list subsequently, concerning the
document:
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:
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
