Subject: [Softwires] Random comments about DHCP discussion

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 30 Jul 2013 13:44:25 +0200

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Jul 2013 12:08:56 +0000

On Jul 30, 2013, at 1:44 PM, Tomek Mrugalski <[email-masked]> wrote:
> implementation simpler.

I think you can infer that the client is willing to do DHCPv4-over-DHCPv6 by looking at the ORO to see if it requests the flag option that enables or disables it.   It may be that all the various partial implementations that are possible can already be inferred from the ORO, but I agree that it is useful to be able to do this, given that we've agreed that partial implementations are expected to happen for ISP-specific deployments.

Thanks for summarizing this.   As you may have noticed, I missed the discussion about why we need to support multiple mappings.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 30 Jul 2013 20:16:57 +0000

Tomek,

> network. 

I can confirm that a single MAP domain is not found to be sufficient in the network for the deployment we have been involved in. 

We are talking about of 100s of domains in the network. 

Cheers,
Rajiv

Sent from my Phone

On Jul 30, 2013, at 7:44 AM, "Tomek Mrugalski" <[email-masked]> wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jul 2013 10:51:54 +0200

Tomek,

> container. Having said all that, I do not object removing the container.

the MAP specification explicitly allows for a MAP CE to belong to multiple MAP domains.

> DHCPv6?" from DHC was "use regular, top level ORO".

I think there should be a goal in designing this DHCP option _NOT_ to require sub-option ORO requests.
also see the discussion on "unified" CPE. if we require this I don't see the point of having
a single DHCP option.

> to differentiate between modes.

right. if I understood Mark's email correctly, I think he made the point that there shouldn't be modes.
a unified CPE supports all. now, if we want to include mechanisms that we have consensus on
not putting on standards track in "unified", that I'm unsure about.

> point is made with my dhc chair hat on.

I think it should be a design goal, that the DHCPv6 option can be "static" and the same
for all clients.

MAP/LW46 has lots of capabilities. hub and spoke, mesh, shared IPv4 address,
full IPv4 address, IPv4 prefix, contiguous or non-contiguous port spaces,
encapsulation or translation, embedded address bits, or 1:1...
I don't think negotiating these capabilities individually via DHCP is at all a good idea.
a general CPE confirming with the MAP/LW46 specifications must implement all features.
in a controlled environment, e.g. where the SP controls both CPE, BR and provisioning, a CPE
might only implement a subset. that's not something we need to cover in the specs though.

> rather uncommon in existing implementations.

as stated above, I think we've lost if we end up with capabilities negotiations.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 31 Jul 2013 13:14:14 +0000

> also see the discussion on "unified" CPE. if we require this I don't see the point of having

I think it's fine to specify the encapsulated options in a top-level ORO.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 31 Jul 2013 19:27:01 +0200

> the MAP specification explicitly allows for a MAP CE to belong to multiple MAP domains.

...on a single interface?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ole Troan <[email-masked]>
Date: Wed, 31 Jul 2013 23:20:11 +0200

Simon,

> ...on a single interface?

yes, and it would also require two separate IPv6 prefixes delegated to the CE.
the most obvious use case would be a renumbering event.

cheers,
Ole