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>
<http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model>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
