[Softwires] Random comments about DHCP discussion

[Tomek Mrugalski <[e-mail]>]

Here are some random comments about draft-ietf-softwire-map-dhcp-04
draft:

1. These are the original reasons for using MAP (now Softwire46)
container:
http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html

They can be summarized as: It was impossible to get a clear confirmation
that only a single MAP domain will ever be configured on a given
network. MAP design was fluctuating. Also, it is unclear what use cases
may come out of Homenet, especially with regards to multiple
provisioning domains. Keeping the S46 options in a separate container
give us more likelihood of future compatibility with whatever may come
our way (from Homenet, from MIF and multiple provisioning domains or
somewhere else).

As I said before, none of the arguments on its own is strong enough to
warrant a container, but taking them all together they are convincing
enough (in my personal option, with my dhc chair hat off) to go with a
container. Having said all that, I do not object removing the container.

2. I brought the question on how to request sub-options in DHCPv6. It
was discussed couple meetings ago in DHC session. The draft was named
http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt.
The answer I got for the question "how to request sub-options in
DHCPv6?" from DHC was "use regular, top level ORO".

3. If you look at the evolution of map-dhcp draft, it is somewhat
worrying. There used to be an enum field that clearly specified the mode
(at that time it was only MAP-E or MAP-T, but it was trivial to extend
the enum list to cover other cases). That was removed as requested. Now
the argument is being made that the CPE does not know which mode it
should run. Even more, options are being split to provide the capability
to differentiate between modes.

4. DHCPv6 server can discover DHCPv6 client's capabilities in two ways.
The first and more obvious one is to draw conclusions from contents of
ORO. The other one that is less common, but equally valid is to make the
client send an option (note the difference: send an actual option, not
option code in ORO). See rapid-commit option for example. If you choose
to do that, I encourage you to read draft-ietf-dhc-option-guidelines,
section 5.2 for a nice discussion how to use such an option. That's
point is made with my dhc chair hat on.

5. Ian insisted on having a way to communicate that a certain CPE is
able to support only EA-len 0. I suppose you could make the same
argument about trimming down other capabilities in an arbitrary way to
have a subset of MAP/lw4over6/whatever-else-you-want to make its
implementation simpler. Perhaps it would be useful to have the
capability to communicate CPE capability? Although not very popular, it
is possible for clients to send options they are requesting from the
server with values used as hints. See 4th paragraph in section 17.1.1 of
RFC3315 for details. Classic example is a client that sends IA_NA option
with IAADDRESS in it with preferred and valid lifetimes set to values
the client would like to get. That gives the server the information
about client's preference. However, it should be clear that those values
are hints only. Server is certainly allowed to ignore them completely.
On a practical side, support for such capability is available, but
rather uncommon in existing implementations.

Hope that helps,
Tomek