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
------------------------------------------------------------------------
_______________________________________________
Autoconf mailing list
Autoconf at ietf.org
https://www.ietf.org/mailman/listinfo/autoconf
