Le 17/11/2011 14:59, Tomek Mrugalski a écrit :
Hi, This thread is about concerns regarding
draft-ietf-mif-dhcpv6-route-option. At the moment this thead was
started, the latest version is -03. See response to concern 3 below
for proposed changes planned for -04. They will be implemented if
the decision is made to continue this work. The latest presentation
about this work was presented in DHC. It differs significantly
compared to what was presnted in MIF. The major changes are: - option
format to be unified to match RA - options from RA and DHCP do not
override each other, but are merged instead (data delivered over DHCP
are functional equivalent of receiving yet another RA).
The goal of this thread and its "in favor" counter-part is to get
input for chairs, ADs and possibly whole IESG whether work on route
option should continue or not.
There was substantial discussion during last MIF meeting, with
follow-ups off the list. I tried to assemble major concerns raised.
I'm sorry if I missed anything. If you want to expand this list,
please add a number for easier reference.
On 11-11-16 17:14, Stuart Cheshire wrote:
Some of my concerns with the DHCPv6 route option are:
1. It duplicates what RA already does. I do not like duplication.
It is *more* than double the work, because not only do you have to
implement two things, you also have to worry about how those two
things interact. Testing is more than twice as hard. Instead of
just testing RA, now you have to test RA alone, DHCPv6 route option
alone, and RA + DHCPv6 together.
Tomek's comment: You can choose to: - not support DHCPv6 at all
(using RA-only) - use DHCPv6, but not request route options (and keep
using RA) - use DHCPv6, request route options and use RA
There should be a 4th possible way:
- use DHCPv6 and not use RA.
Only the third option has the properties that you describe. I do not
think that vendors suddenly jump to route option, start producing
CPEs that use DHCP only and stop announcing RA. (therefore I haven't
mentioned 4th option: use DHCPv6 exclusively and do not support RA)
Stuart's answer: This sounds intentionally naïve about how standards
evolve. The existence of two different sanctioned ways of doing
things means that some vendors (and network operators) will do things
one way and other vendors (and network operators) will do things the
other way, and user pain will result.
In this particular case, I believe a number of vendors currently deploy
both DHCPv6 and RA in some devices. I do not see conflict shaping up
until we mention default route. In the past, similar conflict shaped up
with DNS server (provide with DHCP vs RA), and solved with lists of
preferences.
Wojciech's answer: Fair point, but the alternatives cause pain for
the network operator. A balance needs to be found, and that balance
does not appear to involve "loose DHCP" or "loose RAs". Developing
towards an eco-system of "user and his device" and
"no-one-else-matters" is also sounding intentionally naive.
Stuart's comment #2: That sounds suspiciously like an attempt to
bully and blackmail client vendors into having to do extra
development, testing and support work that they did not willingly
consent to, for someone else's convenience.
Wojciech's response to #2: That plays both ways: Having a client
vendor's convenience that forces network operators to change how they
run their business, and support also looks like bullying. The balance
appears to be in the middle.
2. Its syntax and semantics are different to RA. If we're going to
duplicate RA, at least keep it as similar as possible.
Tomek's answer: Agree. If we decide to continue work on this, I'll
work with Dave Thaler on unifying format and conveyed information
between RA and route option. Would you like to review a draft version
before we publish it as -04?
Sorry for interfering - I would like to if possible.
3. Rather than overriding RA, DHCPv6 route option data should
merge in with other RA data.
Tomek's answer: I wasn't very clear in my presentation. My proposal
about favoring DHCP was only in case of conflicting route entries.
Tomek, this may sound too strong. DHCPv6 default route is a new thing;
text recognizing the reality of existing (RA default route) base should
prevail now. Indicating otherwise provokes negative reaction. As time
goes, implementations may head towards DHCPv6 default route, or not.
Standards Track, Draft Standard, BCP - are much recognition of existing
reality at their respective time.
Discussion during presentation and many follow-ups showed that this
approach would work in some cases, but not in all. I think we should
consider following changes to -03:
a. explain in which conditions this will not work, describe them and
keep the preference as was proposed. Note that the approach of
delivering RA to all hosts and then override for some hosts on a per
hosts basis is a valid argument in favor of this approach. It seems
that at this stage this would exclude homenet from deploying this
mechanism (but please see point 5. below). Lorenzo Colitti (Google)
noted that applicability statements do not prevent anything and are
often ignored.
b. merge data between DHCP and RA. From OS perspective the route
provisioning over DHCP could be roughly perceived as reception of
yet another RA, with equal treating.
YEs, I agree with this, implementation at hand. Our implementation of
DHCP default route merges DHCP data into ND data structures.
4. Speaking as an employee of one of the client vendors, I have
not seen any compelling argument why we should have to do a bunch
of extra work to satisfy some other unspecified people.
There is dedicated thread for support voices.
5. (new point). There is another problem raised by Lorenzo and
further expanded by Ted Lemon that manifests itself in homenet
deployment (but possibly could affect other deployments as well). In
homenet architecture, one of the deployment models is one LAN network
with 2 CPEs that connect to 2 different ISPs. If those CPE also offer
DHCP, client will choose only one advertise and completely ignore the
second. In case of failure of this CPE, client doesn't have any
ability to learn the other set of parameter that the second DHCP
server would have provided. That is general problem of DHCP protocol
and affects all other options that DHCP can provide (including
addresses, delegated prefixes, and options like DNS or routing). Ted
Lemon started working on this problem. See presentation about DHCPv6
and Multihoming problem statement in DHC WG. Presentation is not up
yet, but hopefully it will appear here:
http://tools.ietf.org/agenda/82/dhc.html
6. Doom of RA. Lorenzo Colitti described set of events that he
predicts will happen that will eventually lead to a collapse of the
whole RA model. As a vendor of mobile devices, he afraids that once
route option is defined, some CPE vendors will adopt it. This will
force mobile device vendors to support route option. Once it becomes
more popular, some CPE vendors may decide to stop announcing RA. This
will enable operation without RA. Not needing it, RA will become
essentially obsolete. This in turn will make the benefits of dynamic
configuration offered by RA and put us back with static configuration
that is known from IPv4. I can't comment on feasibility of this
scenario as I don't have operational experience. During follow up
discussions, several people pointed out that this is an excessively
pessimistic scenario.
DHCPv4 is probably the only widespread auto-configuration mechanism used
to manage large networks, thanks to its centralized database and
distributed relays.
For IPv6, I am not aware of such widespread auto-configuration mechanism
(free IPv6 doesn't use DHCPv6 but some different 6rd relying on IPv4).
It may be possible that DHCPv6 will be grown to manage large IPv6
networks as well.
Alex
Please add your favourite reason, why this option should not be
deployed here. On the other hand, if you are supporter of this
option, there is a separate thread for this as well.
On a presonal note, my involvement in this work is on hold until
this issue is resolved.
Cheers, Tomek Mrugalski ISC
_______________________________________________ mif mailing list
[email protected] https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mif
