Subject: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Oct 2012 13:30:57 +0000

The authors of this draft have asked the DHC working group to adopt it as a work item.

This document describes a new DHCPv4 option which allows the DHCPv4 server to assign a set of ports to a user device during the IPv4 address provisioning process.  By assigning the same IPv4 address with non-overlaped port sets to multiple clients, the clients can share the IPv4 address and continue to deliver IPv4 services to subscribers.

Remember, the document just describes the DHCP option, not the whole lightweight 4over6 work.   If you support working on a draft documenting such an option, and are willing to start from this work, please say so on the mailing list.   If you think the working group shouldn't do this work, or that this draft is the wrong place to start, please say so on the mailing list.

We will evaluate working group consensus for adoption on October 24.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 10 Oct 2012 17:10:45 +0000

Support.

Tina

On Oct 10, 2012, at 6:31 AM, "Ted Lemon" <[email-masked]> wrote:

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

---

From: Peng Wu <[email-masked]>
Date: Thu, 11 Oct 2012 16:10:28 +0800

I support to adopt this document.
We've been on this topic for quite a long period. I'm happy to hear
that we finally makes technical progress and produces this latest
draft which describes the problem and the approach clearly.

we can make technical progress and produce this new, latest draft.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 17 Oct 2012 09:25:55 -0400

This is needed. I support it.

---

From: <[email-masked]>
Date: Wed, 17 Oct 2012 15:27:19 +0200

Support.

---

From: Ole Trøan <[email-masked]>
Date: Wed, 17 Oct 2012 19:52:44 +0200

> Remember, the document just describes the DHCP option, not the whole lightweight 4over6 work.   If you support working on a draft documenting such an option, and are willing to start from this work…

what about this draft?
http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 

the MAP effort is using a different port algorithm, with a DHCPV6 option specified here:
http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-03#section-4.4

do we need 2,3,4 DHCP options for all of this variants?
softwire went through quite an exercise to decide on a port allocation scheme for the stateless solutions.
I'm not sure I see the justification for using a different algorithm for "configured" A+P tunnels.

I think it is premature to adopt this in DHC (I'm not against defining an option for this, but _this_ isn't defined yet).

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Wed, 17 Oct 2012 14:07:23 -0400

Rather obviously, the Wu draft was superseded by the present one.

>> The authors of this draft have asked the DHC working group to adopt it as a work item.
...

> http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-03#section-4.4
...

---

From: Ole Trøan <[email-masked]>
Date: Wed, 17 Oct 2012 20:13:12 +0200

Tom,

> Rather obviously, the Wu draft was superseded by the present one.

what about the other questions?
why this style of port mapping as opposed the any other? in particular one that has consensus in softwires already...

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Oct 2012 18:59:43 +0000

> why this style of port mapping as opposed the any other? in particular one that has consensus in softwires already...

There seems to be a lot of effort going into fancy port mapping algorithms which do not make an attacker's job noticeably harder.   The decision here was to simply map out a contiguous range, and allow the gateway to do port randomization within that range.   It is understood that the effectiveness of port range randomization goes down as the port range grows smaller, but it's also understood that there isn't anything we can actually do about this—address sharing unavoidably makes guessing ports easier.

Any deterministic algorithm that isn't a straightforward port range simply adds complexity without adding benefit: there's nothing secret about it—an attacker can just reverse it, and there is no way to keep secret from the attacker what algorithm has been chosen.   Consequently these alternative algorithms were removed from consideration.

Seeded random number algorithms were discussed, but implementation was considered unlikely, and so it was decided that they weren't worth bothering with.   My own conversations with service providers have indicated a strong preference for simplicity here to avoid interoperability problems when implementations accidentally differ.

The MAP folks should just use port ranges.   There is no need for them to do their own port set allocation option.

---

From: Ole Trøan <[email-masked]>
Date: Wed, 17 Oct 2012 22:23:07 +0200

Ted,

> There seems to be a lot of effort going into fancy port mapping algorithms which do not make an attacker's job noticeably harder.   The decision here was to simply map out a contiguous range, and a…

the port mapping algorithm I'm talking about (http://tools.ietf.org/html/draft-ietf-softwire-map-02) is
a) not fancy
b) does not do any port randomization.

which one are you referring to?

> Any deterministic algorithm that isn't a straightforward port range simply adds complexity without adding benefit: there's nothing secret about it—an attacker can just reverse it, and there is no w…

in agreement with you there. which ones did you remove?

> Seeded random number algorithms were discussed, but implementation was considered unlikely, and so it was decided that they weren't worth bothering with.   My own conversations with service provide…

agree.

> The MAP folks should just use port ranges.   There is no need for them to do their own port set allocation option.

they do just use port ranges. please read the proposal.

why do you want to standardize yet another representation of port ranges? if you have to, do it in softwires (and don't use discontiguous masks).

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 01:52:32 +0000

> which one are you referring to?

I haven't read that draft—I'm referring to the two drafts that were merged to produce the current draft, to which you are objecting.   The port randomization is done on the gateway, and is not part of the port set option—it's just the standard port randomization algorithm we've been using for years, only with a smaller set of ports to choose from.   I don't think the new documents even specify the algorithm, since it's not new.

> in agreement with you there. which ones did you remove?

I didn't remove any.

> why do you want to standardize yet another representation of port ranges? if you have to, do it in softwires (and don't use discontiguous masks).

I want there to be one DHCP option that is used by all address-sharing solutions.   If you think this option is the wrong option, by all means propose changes.    Softwires is no better a place to work on this option than dhc; as a regular participant in dhc, it seems to me that it's equally convenient for you either way.   It's also my understanding that Qi Sun et al. are doing this work as part of a larger effort that is taking place in softwires.

Honestly, I'm not that up on the details of the debate in softwires.   It was my understanding that a resolution had been reached, and that the lightweight 4over6 draft that Qi Sun, et al., have been working on was adopted.   If this is not the case, I am interested to know.

But this is not the first time that you've objected to drafts that purport to solve DHCP-related problems as part of that softwires work.   When I've asked you before, you haven't responded by telling me that my understanding of the situation in softwires is incorrect.   If it _is_ incorrect, please do tell me in what way it is incorrect, so that I can stop laboring under false assumptions.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 18 Oct 2012 09:16:13 +0200

Ted,

> I haven't read that draft—I'm referring to the two drafts that were merged to produce the current draft, to which you are objecting.   The port randomization is done on the gateway, and is not part…

the algorithm I'm talking about is the one for choosing the port set. not about how the outside NAT randomly chooses source ports from the given port set.

>> in agreement with you there. which ones did you remove?

earlier in the thread you said the following:

   "Any deterministic algorithm that isn't a straightforward port range simply =
    adds complexity without adding benefit: there's nothing secret about it=97a=
    n attacker can just reverse it, and there is no way to keep secret from the=
    attacker what algorithm has been chosen.   Consequently these alternative =
    algorithms were removed from consideration."

at least I read the last sentence to imply that you had done a evaluation of different algorithms and removed some.

please see http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04
for an analysis of the various proposals.

> I want there to be one DHCP option that is used by all address-sharing solutions.   If you think this option is the wrong option, by all means propose changes.    Softwires is no better a place to…

there is already consensus in softwires on a port mapping algorithm. that is specified in
http://tools.ietf.org/html/draft-ietf-softwire-map-02#section-5

with the corresponding DHCPv6 option in:
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.4

softwire has worked for a long time on port mapping, and it doesn't seem sensible to me that DHC should redo all those decisions and acquire the expertise already there.

we _could_ standardize different port mapping algorithms for DHCPv4 and DHCPv6, or different ones for the plethora of A+P type mechanisms, but I'm at least aren't convinced that we need more than one simple scheme.

> Honestly, I'm not that up on the details of the debate in softwires.   It was my understanding that a resolution had been reached, and that the lightweight 4over6 draft that Qi Sun, et al., have be…

as far as I can see (http://datatracker.ietf.org/wg/softwire/) Lightweight 4over6 is not adopted by the working group.

> But this is not the first time that you've objected to drafts that purport to solve DHCP-related problems as part of that softwires work.   When I've asked you before, you haven't responded by tell…

I am pretty sure that your understanding of the situation in softwires is incorrect.
(I'm also pretty sure that my understanding of the situation in softwires is incorrect. ;-))

may I suggest that the DHC and softwire chairs get together and get a common understanding?

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 18 Oct 2012 10:03:49 +0200

Hi,

this option cannot be used to extend regular IPv4 clients or DHCP servers
to serve on plain IPv4-only networks, ie it fits into a wider
solution/architecture context which is not being covered by the DHC WG.
While acknowledging that "some option" needs to be defined, defining it in
DHC seems like not the right approach. Furthermore, there are several
overlapping solutions here, which can be addressed by a common DHCP spec.
Rather interestingly
http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 was a step in
the right direction, with draft-sun-dhc-port-set-option regressing.

As such I do not support the adoption of this draft.

Regards,
Woj.

On 10 October 2012 15:30, Ted Lemon <[email-masked]> wrote:

> This document describes a new DHCPv4 option which allows the DHCPv4 server
> to assign a set of ports to a user device during the IPv4 address
> provisioning process.  By assigning the same IPv4 address with
> non-overlaped port sets to multiple clients, the clients can share the IPv4
> address and continue to deliver IPv4 services to subscribers.
>
> Remember, the document just describes the DHCP option, not the whole
> lightweight 4over6 work.   If you support working on a draft documenting
> such an option, and are willing to start from this work, please say so on
> the mailing list.   If you think the working group shouldn't do this work,
> or that this draft is the wrong place to start, please say so on the
> mailing list.
>

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 18 Oct 2012 12:20:01 +0200

I support this document.

Best Regards,
Ales

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
> Lemon
> Sent: Wednesday, October 10, 2012 3:31 PM
> To: dhcwg WG
> Subject: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option
> 
> This document describes a new DHCPv4 option which allows the DHCPv4 server to
> assign a set of ports to a user device during the IPv4 address provisioning process.  By
> assigning the same IPv4 address with non-overlaped port sets to multiple clients, the
> clients can share the IPv4 address and continue to deliver IPv4 services to subscribers.
> 
> Remember, the document just describes the DHCP option, not the whole lightweight
> 4over6 work.   If you support working on a draft documenting such an option, and are
> willing to start from this work, please say so on the mailing list.   If you think the
> working group shouldn't do this work, or that this draft is the wrong place to start,
> please say so on the mailing list.
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Oct 2012 09:12:57 -0400

Le 2012-10-18 04:03, Wojciech Dec a écrit :
> this option cannot be used to extend regular IPv4 clients or DHCP
> servers to serve on plain IPv4-only networks

Why not? From reading the draft, it looks to me like it can.

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 Trøan <[email-masked]>
Date: Thu, 18 Oct 2012 15:28:11 +0200

Simon,

> Why not? From reading the draft, it looks to me like it can.

the option is there to give a shared IPv4 address to the DHCP client.
example; two hosts on a the network. one gets IPv4 address 1.1.1.1 port range 1001-4000,
the other IPv4 address 1.1.1.1 port range 4001-8000.

without a "larger context" (i.e. some sort of encapsulation, how is that supposed to work? think ARP.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 13:34:26 +0000

> without a "larger context" (i.e. some sort of encapsulation, how is that supposed to work? think ARP.

Just to be clear here, the DHC working group is not proposing to work on defining a way to share IP addresses.   The DHC working group is proposing to work on a way to convey a port range to a device which shares IP addresses, using DHCP.   Anything more than that would definitely be out of scope for DHC.

BTW, we discussed using port ranges versus using masks; the reason for using masks is that it's easier to do on the fast path than ranges.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 18 Oct 2012 15:38:52 +0200

> BTW, we discussed using port ranges versus using masks; the reason for using masks is that it's easier to do on the fast path than ranges.

right. draft-ietf-softwire-map uses a mask. you propose support for a  discontiguous mask, our proposal a contiguous one. anyhow, let us move this to softwire.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Thu, 18 Oct 2012 16:00:44 +0200

> This draft does proposed a contiguous mask to allocate contiguous port-set. And the draft is a merged version of 
> draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. The authors have reached the consensus to use mask for contiguous port-set allocation, which is easy to implement both for client and server.

if this proposal is also advocating a contiguous mask, then I don't understand why you cannot use the proposal in draft-ietf-softwire-map?

cheers,
Ole

---

From: sunqi <[email-masked]>
Date: Thu, 18 Oct 2012 21:56:46 +0800

Hi Ole,

Best Regards!

Qi Sun

---

From: Peng Wu <[email-masked]>
Date: Thu, 18 Oct 2012 22:31:56 +0800

Tom,

Thanks for the clarification.
Let me provide some further backgound info here as an author of draft-wu.
There were two drafts on this subject, draft-bajko and draft-wu,
providing different types of option formats, with slightly different
concerns and effects.
I gave a joint presenation on these two drafts in Vancouver. While the
sense in the room was this document is needed, people did suggest to
narrow the option numbers down.
So, after last IETF, the authors of the two drafts along with the
chairs spent quite a long time to discuss the accurate requirements,
and come up with one option and a new, merged draft, which is
draft-sun.
Hope this can clear things up.

---

From: <[email-masked]>
Date: Thu, 18 Oct 2012 16:37:21 +0200

Hi Peng,

In addition to what you mentioned, what has been reached also among authors of draft-sun-dhc-port-set-option is to define a simple option to convey a contiguous port range. It was also agreed to use port masks instead of port bounds.  

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Peng Wu
>Envoyé : jeudi 18 octobre 2012 16:32
>À : Tom Taylor
>Cc : [email-masked]
>Objet : Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option
>
>Tom,
>
>>>> The authors of this draft have asked the DHC working group 
>to adopt it as
>>>> a work item.
>>
>> ...
>>
>>
>>>
>>> what about this draft?
>>> the MAP effort is using a different port algorithm, with a 
>DHCPV6 option
>>> specified here:
>>>
>>>

---

From: Peng Wu <[email-masked]>
Date: Thu, 18 Oct 2012 22:39:35 +0800

Ole,

first of all, we all know that contiguous port range is a very special
case of the general MAP algorithm

second, I'm sensing that Ted's points is that the effort of MAP to
produce non-contiguous port set is to make the ports look like
"randomized" from outside, although generated in a deterministic way.
That is also my understanding. But eventually it falis to achieve that
once an attacker learns the deterministic algorithm.
That's why we decided to remove MAP from the option list during the
discussion of producing the new draft.

---

From: Qi Sun <[email-masked]>
Date: Thu, 18 Oct 2012 22:42:42 +0800

Hi Ole,

> if this proposal is also advocating a contiguous mask, then I don't understand why you cannot use the proposal in draft-ietf-softwire-map?

The proposal in draft-ietf-softwire-map includes case of  allocating non-contiguous port-sets to a CE. Non-contiguous port-set can't make it harder to guess the port, with extra effort for implementation.  A contiguous port-set is enough and can be achieved easily.

Thanks,

Qi Sun

---

From: Peng Wu <[email-masked]>
Date: Thu, 18 Oct 2012 22:45:19 +0800

If we only need contiguous port range as you said, we only need a
contiguous mask and that's all. Perfect match. No other MAP parameters
or non-contiguous port set format as an outcome of MAP.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 18 Oct 2012 16:53:57 +0200

> The proposal in draft-ietf-softwire-map includes case of  allocating non-contiguous port-sets to a CE. Non-contiguous port-set can't make it harder to guess the port, with extra effort for implemen…

MAP isn't encoded the way it is to make it hard to guess, it is to avoid the well known ports, without reserving a particular "port set id" as you call it.

with an offset = 0, you get your scheme with MAP.

what you appear to describe is what I previously called a "port prefix", and something you could represent as:
<port>/<port-prefix length>. e.g. 0x14/6 to use your example in the draft.

again, what are your benefits over the existing MAP proposal that has already achieved consensus?
why do we need yet another one?

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Thu, 18 Oct 2012 22:56:14 +0800

indeed. The contiguous port mask is one example of MAP algorithm. But we
hope to simplify it from both implementation and operational point of view,
by removing all these parameters and algorithms. Contiguous port-set using
port mask is all we need, so we do not need anything more.

And besides, what we need is a DHCPv4 option, not DHCPv6.

Best wishes
Qiong

On Thu, Oct 18, 2012 at 10:45 PM, Peng Wu <[email-masked]> wrote:

> >> This draft does proposed a contiguous mask to allocate contiguous
> port-set. And the draft is a merged version of
> >> draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. The
> authors have reached the consensus to use mask for contiguous port-set
> allocation, which is easy to implement both for client and server.
> >
> > if this proposal is also advocating a contiguous mask, then I don't
> understand why you cannot use the proposal in draft-ietf-softwire-map?
> >
> > cheers,
> > Ole
> >

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Qi Sun <[email-masked]>
Date: Thu, 18 Oct 2012 22:59:05 +0800

again, what are your benefits over the existing MAP proposal that has
already achieved consensus?

[Qi] The contiguous port-set with port mask is simple and clean. And it's
easier to understand, especially as a DHCP option.

BR,
Qi Sun

On Thu, Oct 18, 2012 at 10:53 PM, Ole Trøan <[email-masked]> wrote:

> > The proposal in draft-ietf-softwire-map includes case of  allocating
> non-contiguous port-sets to a CE. Non-contiguous port-set can't make it
> harder to guess the port, with extra effort for implementation.  A
> contiguous port-set is enough and can be achieved easily.
>
> MAP isn't encoded the way it is to make it hard to guess, it is to avoid
> the well known ports, without reserving a particular "port set id" as you
> call it.
>

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 18 Oct 2012 17:05:59 +0200

On 18 October 2012 15:34, Ted Lemon <[email-masked]> wrote:

> Just to be clear here, the DHC working group is not proposing to work on
> defining a way to share IP addresses.   The DHC working group is proposing
> to work on a way to convey a port range to a device which shares IP
> addresses, using DHCP.   Anything more than that would definitely be out of
> scope for DHC.
>

It may be worthwhile to ask "why" then are these ranges needed, if not for
the specific solutions in softwires?
The sharing of IP addresses on a "regular v4" network has been  documented
as "bad",
http://tools.ietf.org/html/draft-thaler-port-restricted-ip-issues-00

Now, given that there are several nuances of the solutions for "v4 networks
over v6", with address sharing, it stands to reason that the solution group
defining these should also define the option and consult DHC accordingly,
rather than the other way round.

Regards,
Woj.

>
> BTW, we discussed using port ranges versus using masks; the reason for
> using masks is that it's easier to do on the fast path than ranges.
>

---

From: Ole Trøan <[email-masked]>
Date: Fri, 19 Oct 2012 10:29:07 +0200

> indeed. The contiguous port mask is one example of MAP algorithm. But we hope to simplify it from both implementation and operational point of view, by removing all these parameters and algorithms. Contiguous port-set using port mask is all we need, so we do not need anything more. 

I don't think we'll get anywhere with each of us claiming that "our" algorithm is simpler than yours.
it might be that the formal text in the MAP draft confuses the matter unduly.

let me try and explain again. MAP is based on the very simple idea of describing a port range as a port prefix.
for example I give you the port prefix 10.0/8, if we want to use the same notation as we do for IP prefixes.
10/8 is 256 ports, in the range from 2560 - 2815.

   0                          8                         15
   +---------------+----------+--------------------------+
   | Port Prefix / PSID       |       Port range         |
   +---------------+----------+--------------------------+

for this you need two parameters, port prefix and port prefix length. that is the simplest scheme that anyone has proposed as far as I know.
do you agree?

then the _only_ thing MAP does that is different from the above, is to introduce one more configuration parameter, the offset.
so that instead of it being purely a port _prefix_, the PSID can be a port _infix_ or port _post-fix_.

represented something like this:

   0                          8                         15
   +---------------+----------+--------------------------+
   | Port range    |         PSID       |  Port range    |
   +---------------+----------+--------------------------+

the problem with the port prefix (offset=0) in the top figure for the use as embedded address bits, is that when the PSID is 0 then you'll end up giving the system ports to a user. that would typically not be what you want, and recommending an offset = 4, and the first port range > 0, effectively excludes the system ports. for the case where you create DHCP binding state per customer, you can just make sure to never assign PSID = 0, so in your case you can of course use offset=0

are you still with me?

> And besides, what we need is a DHCPv4 option, not DHCPv6.

why? that's certainly not the only solution. given that you need a DHCPv6 option to provision your IPv4 DHCP server. plus a lot of new complex IPv4 DHCP machinery...?
there is already a DHCPv6 option in process of being standardised. you already depend on options from DHCPv6. why not reuse those existing protocol mechanisms? 

what I would suggest:
  - you merge with / ensure you have your requirements fulfilled by
    draft-ietf-softwire-map-dhcp-01
  - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provisioning, using draft-ietf-softwire-map-dhcp

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 19 Oct 2012 11:38:38 +0200

Dear Ole,

Please see inline.
Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Ole Trøan
Envoyé : vendredi 19 octobre 2012 10:29
À : Qiong
Cc : sunqi; <[email-masked]>; Ted Lemon
Objet : Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option

why? that's certainly not the only solution. given that you need a DHCPv6 option to provision your IPv4 DHCP server. plus a lot of new complex IPv4 DHCP machinery...?
[Med] IMO the DHCPv6 option to configure the IPv4 DHCP server is not mandatory. The SI can assume its SC being its DHCPv4 server.

there is already a DHCPv6 option in process of being standardised. you already depend on options from DHCPv6. why not reuse those existing protocol mechanisms?
[Med] This is a good point. We discussed it (i.e., include IPv4 address as an IPv4-mapped IPv6 address) and even documented it here:
http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-08#appendix-A. But this was abandoned because we was told it is easy to manage transition-specific codes in DHCPv4 rather than DHCPv6. I don't remember well the details but it is something related to the exit strategy for these specific codes at the client side.
what I would suggest:
  - you merge with / ensure you have your requirements fulfilled by
    draft-ietf-softwire-map-dhcp-01
  - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provisioning, using draft-ietf-softwire-map-dhcp
[Med] Given what I understood to be the position of the DHC WG, a DHCPv4 option is needed for lw4over6.

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Fri, 19 Oct 2012 17:50:25 +0800

Hi Ole,

Inline please.

BR,
Qi

On Fri, Oct 19, 2012 at 4:29 PM, Ole Trøan <[email-masked]> wrote:

> let me try and explain again. MAP is based on the very simple idea of
> describing a port range as a port prefix.
> for this you need two parameters, port prefix and port prefix length. that
> is the simplest scheme that anyone has proposed as far as I know.
> do you agree?
>

[Qi] This is what we do in draft-sun-*. Just need the port prefix and port
prefix length to allocate one contiguous port-set. No other specific paras
are needed.

>
> then the _only_ thing MAP does that is different from the above, is to
> introduce one more configuration parameter, the offset.
> the problem with the port prefix (offset=0) in the top figure for the use
> as embedded address bits, is that when the PSID is 0 then you'll end up
> giving the system ports to a user. that would typically not be what you
> want, and recommending an offset = 4, and the first port range > 0,
> effectively excludes the system ports. for the case where you create DHCP
> binding state per customer, you can just make sure to never assign PSID =
> 0, so in your case you can of course use offset=0
>
> are you still with me?
>
> why? that's certainly not the only solution. given that you need a DHCPv6
> option to provision your IPv4 DHCP server. plus a lot of new complex IPv4
> DHCP machinery...?
> there is already a DHCPv6 option in process of being standardised. you
> already depend on options from DHCPv6. why not reuse those existing
> protocol mechanisms?
>
> what I would suggest:
>   - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete
> provisioning, using draft-ietf-softwire-map-dhcp
>
> cheers,
> Ole
>

---

From: Ole Trøan <[email-masked]>
Date: Fri, 19 Oct 2012 12:34:39 +0200

Qi,

> [Qi] This is what we do in draft-sun-*. Just need the port prefix and port prefix length to allocate one contiguous port-set. No other specific paras are needed.

there is a port mapping algorithm and DHCP option as working group adopted drafts already, that has 3 parameters; port prefix, prefix length and offset. you think it is necessary for the industry to have a separate document to describe the exact same subset of the option above, but with 2 parameters; port prefix and prefix length?

sigh. creating an RFC for _every_ possible solution and option isn't standardisation.

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 19 Oct 2012 13:19:07 +0200

Ole,

As a reminder, this is a call for adoption and not a WGLC.

The encoding can be changed to reflect the WG consensus but we are not there at this stage. The main point is the port mask is compliant with it is documented in the map document. So, there are already synergies between lw4over6 and map efforts. Is there a need to import all map specific parameters into draft-sun-dhc-port-set-option? IMO, this is a discussion point we can work on when we advance in the lw4over6 specification.

draft-sub-* is defining a DHCPv4 option not a DHCPv6 one. As such your proposal does not work. I already explained why we abandoned the DHCPv6 track for this work.

Cheers,
Med

>la part de Ole Trøan
>Envoyé : vendredi 19 octobre 2012 12:35
>À : Qi Sun
>> [Qi] This is what we do in draft-sun-*. Just need the port 
>prefix and port prefix length to allocate one contiguous 
>port-set. No other specific paras are needed.
>
>there is a port mapping algorithm and DHCP option as working 
>group adopted drafts already, that has 3 parameters; port 
>prefix, prefix length and offset. you think it is necessary 
>for the industry to have a separate document to describe the 
>exact same subset of the option above, but with 2 parameters; 
>port prefix and prefix length?
>

---

From: Qi Sun <[email-masked]>
Date: Fri, 19 Oct 2012 19:19:22 +0800

Hi Ole,

IMHO, you refer to a DHCPv6 option for allocating IPv4 address-related
resources, right? I think Med's email has explained the reasons clearly.

Qi

On Fri, Oct 19, 2012 at 6:34 PM, Ole Trøan <[email-masked]> wrote:

> Qi,
>
> > [Qi] This is what we do in draft-sun-*. Just need the port prefix and
> port prefix length to allocate one contiguous port-set. No other specific
> paras are needed.
>
> there is a port mapping algorithm and DHCP option as working group adopted
> drafts already, that has 3 parameters; port prefix, prefix length and
> offset. you think it is necessary for the industry to have a separate
> document to describe the exact same subset of the option above, but with 2
> parameters; port prefix and prefix length?
>

---

From: Ole Trøan <[email-masked]>
Date: Fri, 19 Oct 2012 14:32:18 +0200

Med,

> As a reminder, this is a call for adoption and not a WGLC.

indeed. I think 
 a) it shouldn't be adopted without a "customer". i.e. a draft in softwire
 b) it shouldn't be adopted because there is an existing solution progressing in softwire for this already.

> draft-sub-* is defining a DHCPv4 option not a DHCPv6 one. As such your proposal does not work. I already explained why we abandoned the DHCPv6 track for this work.

given that the world has moved on and that we have already defined options to provision IPv4 addresses and port sets in DHCPv6. do you think the reasons for choosing DHCPv4 provisioning still applies? is there any case where you want to use this and you do _not_ have DHCPv6 available? e.g. A+P IPv4 tunneled in IPv4, VLANs etc? (and no, I'm not suggesting someone should standardize any of those. ;-))

Best regards,
Ole

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Oct 2012 14:42:27 +0200

-1 for adoption. 

The work is substantially complete in softwires, and while overlap in
some cases happens, it should happen for good reason.  Ole has explained
that the case you are attempting to cover is already covered by the
softwires draft, and I haven't yet heard any serious argument for
development of an IPv4 option.  If either WG later decides that an IPv4
option IS required it should be based on the existing softwires work.

Eliot

On 10/19/12 11:50 AM, Qi Sun wrote:
> Hi Ole,
>
> Inline please.
>
> BR,
> Qi
>
> On Fri, Oct 19, 2012 at 4:29 PM, Ole Trøan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     indeed. The contiguous port mask is one example of MAP algorithm.
>>     But we hope to simplify it from both implementation and
>>     operational point of view, by removing all these parameters and
>>     algorithms. Contiguous port-set using port mask is all we need,
>>     so we do not need anything more. 
>
>     let me try and explain again. MAP is based on the very simple idea
>     of describing a port range as a port prefix.
>     for example I give you the port prefix 10.0/8, if we want to use
>     the same notation as we do for IP prefixes.
>     for this you need two parameters, port prefix and port prefix
>     length. that is the simplest scheme that anyone has proposed as
>     far as I know.
>     do you agree?
>
>
> port prefix length to allocate one contiguous port-set. No other
> specific paras are needed.
>  
>
>
>     then the _only_ thing MAP does that is different from the above,
>     is to introduce one more configuration parameter, the offset.
>     the problem with the port prefix (offset=0) in the top figure for
>     the use as embedded address bits, is that when the PSID is 0 then
>     you'll end up giving the system ports to a user. that would
>     typically not be what you want, and recommending an offset = 4,
>     and the first port range > 0, effectively excludes the system
>     ports. for the case where you create DHCP binding state per
>     customer, you can just make sure to never assign PSID = 0, so in
>     your case you can of course use offset=0
>
>     are you still with me?
>
>     why? that's certainly not the only solution. given that you need a
>     DHCPv6 option to provision your IPv4 DHCP server. plus a lot of
>     new complex IPv4 DHCP machinery...?
>     there is already a DHCPv6 option in process of being standardised.
>     you already depend on options from DHCPv6. why not reuse those
>     existing protocol mechanisms? 
>
>     what I would suggest:
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 19 Oct 2012 14:47:28 +0200

Re-,

Please see inline.
Cheers,
Med 

>De : Ole Trøan [mailto:[email-masked]] 
>Envoyé : vendredi 19 octobre 2012 14:32
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Qi Sun; sunqi; <[email-masked]>; Ted Lemon

Med: To be accurate, there is already a "customer" for it: RFC6346 (binding table mode).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Oct 2012 14:18:28 +0000

>   - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provisioning, using draft-ietf-softwire-map-dhcp

Right, so the working group already concluded over a year ago that we weren't going to do this, because DHCPv6 servers don't allocate IPv4 addresses.   You claim that the DHCPv6 solution is simpler, but it's not, because it requires permanent changes to DHCPv6.   DHCPv4 is a protocol that is becoming obsolete; using DHCPv4 to deliver IPv4 addresses for transition technology is a big win, because the changes die with the protocol, and don't have to be carried forward forever.

The only additional complexity to the DHCPv4-over-IPv6 solution is to allow it to work in the non-port-range environment for unmodified DHCPv4 clients.

This is a conclusion that the DHC working group draw a long time ago.   The DHC working group adopted the DHCPv4-over-IPv6 work.   That work is near completion.   The call for adoption on this draft is not a referendum on the question of whether we should do DHCPv4-over-IPv6.   We are already doing that.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Oct 2012 14:38:19 +0000

On Oct 19, 2012, at 8:42 AM, Eliot Lear <[email-masked]> wrote:
> The work is substantially complete in softwires, and while overlap in some cases happens, it should happen for good reason.  Ole has explained that the case you are attempting to cover is already covered by the softwires draft, and I haven't yet heard any serious argument for development of an IPv4 option.  If either WG later decides that an IPv4 option IS required it should be based on the existing softwires work.

It's not really within softwires' bailiwick to decide how the DHCP protocol will be extended.   Ordinarily we would expect any such work to be done in the DHC working group.   And indeed quite some time ago people came from softwires to talk about whether to use DHCPv4 or DHCPv6 to solve this problem, and the working group decided to use DHCPv4 and not DHCPv6, for reasons I described in a separate message.

So it may be that softwires has continued on in a different direction since then, but the DHC working group has been working steadily on a solution involving DHCPv4, and it's a bit late to be telling us now that softwires has decided to go against the DHC consensus and break DHCPv6.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Oct 2012 18:11:21 +0200

Hi Ted,

Many points:

On 10/19/12 4:38 PM, Ted Lemon wrote:
> It's not really within softwires' bailiwick to decide how the DHCP protocol will be extended.

I want to answer your statement in three ways.  First, in my reading of
the draft, it makes no changes to classic DHCP behavior.  Therefore, it
seems to me that the protocol itself is not changed.  Rather this Just
Another Option (JAO).  Where do you see differently?  Given the authors
of the draft are dhc regulars, I wouldn't really expect otherwise.

Next, there's the bureaucratic way:

This is what we have charters and ADs for.  Did the softwire group
exceed its charter?  Let's go to the video tape:

> Sep 2011 	Submit DHCPv4 over tunnel document for Proposed Standard
>
I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to
respond to.  I will readily state that charters can often cause
confusion.  Area Directors are responsible for seeing that work occurs
in the right place within the IETF. 

>    Ordinarily we would expect any such work to be done in the DHC working group.   

My personal preference is to do DHCP options in the dhc working group
simply because the experts are there, but as you well know, you can
argue both sides of this issue if there is another competent working
group.  That is– if the underlying meaning of this option is within the
expertise of softwire, then work done here might get overlooked by
them.  Fortunately, both you and the softwire WG chairs are experienced
enough to recognize all of this.

> And indeed quite some time ago people came from softwires to talk about whether to use DHCPv4 or DHCPv6 to solve this problem, and the working group decided to use DHCPv4 and not DHCPv6, for reasons I described in a separate message.

So then I think you have a complaint against the existing softwire draft
that is worthy of a last call comment, and others might as well.  This
is how we end up with one good standard and not two substandard
standards, especially if it breaks DHCP.  I'd suggest that at least one
of the intarea directors knows something about DHCP, and would also take
issue with something that breaks it ;-0

> So it may be that softwires has continued on in a different direction since then, but the DHC working group has been working steadily on a solution involving DHCPv4, and it's a bit late to be telli…

I'm sorry, but I take issue with "late".  We are at the point of
adoption of a draft.  This is PRECISELY the point when one must raise a
concern.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Oct 2012 16:30:48 +0000

On Oct 19, 2012, at 12:11 PM, Eliot Lear <[email-masked]> wrote:
> I'm sorry, but I take issue with "late".  We are at the point of adoption of a draft.  This is PRECISELY the point when one must raise a concern.

No, we are not at the point of adoption of the relevant draft.   We are at the point of adoption of a follow-on draft.   The decision as to what direction to go in was taken over a year ago, and the work is essentially complete.

It may be that the obvious problem with the solution proposed in softwires isn't obvious to everyone, so let me explain in detail.

Suppose for instance you have a port set allocation policy that gives 4096 ports to each CPE device.   In this situation, you have 12 bits of port and 4 bits of address in the port range, and 32 bits of address in the IPv4 address range, for a total of 36 address bits.

In order to allocate the port set, we need to know what IPv4 address the client has, since port sets are only unique to a specific IPv4 address.   If the DHCPv6 server allocates the port set, it must first learn somehow what IPv4 address has been assigned to the CPE device.   Furthermore, there will be a time period between when the IPv4 address is first allocated and when the port set is allocated when the device is unaware that it is sharing its IPv4 address, and may make connections using ports outside of the port set it will eventually be assigned.

So it doesn't make sense to do the IPv4 address assignment in the DHCPv4 server, and the port set assignment in the DHCPv6 server.   Indeed, that simply won't work, for most widely-accepted values of "work."

The real problem that needs to be solved for port set allocation is how to combine an IPv4 address and a port set.   Effectively, the IPv4 address and the port range add up to an address that is somewhere between 32 and 48 bits wide, although numbers approaching 48 are obviously not very useful.   It is easiest to treat this as a simple prefix assignment problem with a 48-bit address, rather than as two separate problems: a port set assignment and an address assignment.

Now, it's entirely possible to solve this problem in the DHCPv6 server.   Nobody would dispute that.   But what the softwires draft does is not that—it simply solves half the problem, and leaves the other half unaddressed: it assigns a port set, but not an IPv4 address.

As I say, to me this is painfully obvious, and so the implication is that since softwires is attempting to advance a DHCPv6 option to solve the port set allocation problem, they have rejected the use of DHCPv4 to allocate IPv4 addresses in the port set allocation context.   It may be that the authors of the softwires draft had no such intention, but this is undeniably the effect that their draft would have if it became the standard.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 19 Oct 2012 19:15:27 +0200

Ted,

As hopefully you'll concede, the sharing IPv4 addresses is a wider
architecture/solution than just defining extensions in DHC. Following the
charter the DHC should play an advisory role on the DHC part, rather than
getting into the merits of port range discussions or not which this thread
featured prominently - a tell tell sign of something really amiss in this
work being in DHC.
And it does not make things right by claiming that the discussion on that,
or another aspect of the solution has been had in DHC for some time already.
Also, as asked previously, is there a case for for the DHCPv4 port
extension, other than the softwire solutions?

Thanks,
Woj.

On 19 October 2012 18:30, Ted Lemon <[email-masked]> wrote:

> No, we are not at the point of adoption of the relevant draft.   We are at
> the point of adoption of a follow-on draft.   The decision as to what
> direction to go in was taken over a year ago, and the work is essentially
> complete.
>
> It may be that the obvious problem with the solution proposed in softwires
> isn't obvious to everyone, so let me explain in detail.
>
> Suppose for instance you have a port set allocation policy that gives 4096
> ports to each CPE device.   In this situation, you have 12 bits of port and
> 4 bits of address in the port range, and 32 bits of address in the IPv4
> address range, for a total of 36 address bits.
>
> In order to allocate the port set, we need to know what IPv4 address the
> client has, since port sets are only unique to a specific IPv4 address.
> If the DHCPv6 server allocates the port set, it must first learn somehow
> what IPv4 address has been assigned to the CPE device.   Furthermore, there
> will be a time period between when the IPv4 address is first allocated and
> when the port set is allocated when the device is unaware that it is
> sharing its IPv4 address, and may make connections using ports outside of
> the port set it will eventually be assigned.
>
> So it doesn't make sense to do the IPv4 address assignment in the DHCPv4
> server, and the port set assignment in the DHCPv6 server.   Indeed, that
> simply won't work, for most widely-accepted values of "work."
>
> The real problem that needs to be solved for port set allocation is how to
> combine an IPv4 address and a port set.   Effectively, the IPv4 address and
> the port range add up to an address that is somewhere between 32 and 48
> bits wide, although numbers approaching 48 are obviously not very useful.
> It is easiest to treat this as a simple prefix assignment problem with a
> 48-bit address, rather than as two separate problems: a port set assignment
> and an address assignment.
>
> Now, it's entirely possible to solve this problem in the DHCPv6 server.
> Nobody would dispute that.   But what the softwires draft does is not
> that—it simply solves half the problem, and leaves the other half
> unaddressed: it assigns a port set, but not an IPv4 address.
>
> As I say, to me this is painfully obvious, and so the implication is that
> since softwires is attempting to advance a DHCPv6 option to solve the port
> set allocation problem, they have rejected the use of DHCPv4 to allocate
> IPv4 addresses in the port set allocation context.   It may be that the
> authors of the softwires draft had no such intention, but this is
> undeniably the effect that their draft would have if it became the standard.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Oct 2012 17:33:23 +0000

On Oct 19, 2012, at 1:15 PM, Wojciech Dec <[email-masked]>
 wrote:
> As hopefully you'll concede, the sharing IPv4 addresses is a wider architecture/solution than just defining extensions in DHC. Following the charter the DHC should play an advisory role on the DHC part, rather than getting into the merits of port range discussions or not which this thread featured prominently - a tell tell sign of something really amiss in this work being in DHC.
> And it does not make things right by claiming that the discussion on that, or another aspect of the solution has been had in DHC for some time already.
> Also, as asked previously, is there a case for for the DHCPv4 port extension, other than the softwire solutions? 

Do you have anything substantive to say?   It's really a lot of work to write out a document explaining the problem on a technical level.   It's disheartening to read a response that completely ignores the explanation and just talks about politics.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 19 Oct 2012 19:47:12 +0200

On 19 October 2012 19:33, Ted Lemon <[email-masked]> wrote:

> > And it does not make things right by claiming that the discussion on
> that, or another aspect of the solution has been had in DHC for some time
> already.
> Do you have anything substantive to say?   It's really a lot of work to
> write out a document explaining the problem on a technical level.   It's
> disheartening to read a response that completely ignores the explanation
> and just talks about politics.
>
> Perhaps it may be worthwhile for you to consider writing that document
then and share it with the rest of us who apparently are not as well
informed.
It's also disheartening to see the DHC chair get ruffled by a debate on
port range formats, which have next to nothing to do with the DHCP
protocol, and ignore basic questions about the scope of the work.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 19 Oct 2012 19:53:28 +0200

> protocol, and ignore basic questions about the scope of the work.

Forgot to add : Your analysis appears to have overlooked a characteristic
of MAP; the IPv4 address can be derived from a combination of IPv4 and IPv6
info.
More stuff in
http://tools.ietf.org/agenda/84/slides/slides-84-softwire-13.pdf (which was
discussed in softwires)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Oct 2012 17:57:08 +0000

On Oct 19, 2012, at 1:47 PM, Wojciech Dec <[email-masked]>
 wrote:
> Perhaps it may be worthwhile for you to consider writing that document then and share it with the rest of us who apparently are not as well informed.

I just did.   The rest of your response tells me that you didn't read it.   Could you please go back and read it?   This is not a debate about port range formats.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 19 Oct 2012 20:24:57 +0200

On 19 October 2012 19:57, Ted Lemon <[email-masked]> wrote:

> I just did.   The rest of your response tells me that you didn't read it.
>   Could you please go back and read it?   This is not a debate about port
> range formats.
>
> If that is the extent of it, then your analysis appears to have overlooked
a characteristic of MAP; the IPv4 address can be derived from a combination
of IPv4 and IPv6 info.
More stuff in
http://tools.ietf.org/agenda/84/slides/slides-84-softwire-13.pdf (which was
discussed in softwires) that indicates plenty of overlap between the
solutions.

As others have said, picking and defining an option in DHC without
consideration of the overall work appears short sighted. Dismissing the
charter aspect also - unless your assertion is that charters don't matter.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Oct 2012 20:26:24 +0200

I think we've crossed the threshold where perhaps this is a good topic
for the ADs, chairs, and perhaps some high bandwidth time in Atlanta?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Oct 2012 21:57:32 +0000

On Oct 19, 2012, at 2:24 PM, Wojciech Dec <[email-masked]> wrote:
> If that is the extent of it, then your analysis appears to have overlooked a characteristic of MAP; the IPv4 address can be derived from a combination of IPv4 and IPv6 info.
> More stuff in http://tools.ietf.org/agenda/84/slides/slides-84-softwire-13.pdf (which was discussed in softwires) that indicates plenty of overlap between the solutions.

The slides don't actually describe how that's done.

> As others have said, picking and defining an option in DHC without consideration of the overall work appears short sighted. Dismissing the charter aspect also - unless your assertion is that charters don't matter.

The DHC working group is chartered with doing DHCP extensions.

It's true that if you have a static mapping between IPv4 and IPv6 address, you don't need DHCPv4.   However, it's not clear to me that this is universally desired.

---

From: Ole Trøan <[email-masked]>
Date: Sat, 20 Oct 2012 03:51:42 +0200

Ted,

> As I say, to me this is painfully obvious, and so the implication is that since softwires is attempting to advance a DHCPv6 option to solve the port set allocation problem, they have rejected the u…

the above is plain wrong.

draft-ietf-softwire-map + draft-ietf-softwire-map-dhcp does let you allocate an IPv4 address, or an IPv4 prefix (does IPv4 prefix delegation), or allocate an shared IPv4 address (A+P). all this is done with a DHCPv6 option. with or without embedded address bits.

just like DHCPv4 option 212 is used to allocate an IPv6 prefix, the MAP DHCPv6 option is used to allocate IPv4 parameters.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Oct 2012 04:09:56 +0000

> draft-ietf-softwire-map + draft-ietf-softwire-map-dhcp does let you allocate an IPv4 address, or an IPv4 prefix (does IPv4 prefix delegation), or allocate an shared IPv4 address (A+P). all this is…

You are confusing representation with mechanism.   What is the mechanism whereby this address is allocated?

---

From: Peng Wu <[email-masked]>
Date: Sat, 20 Oct 2012 14:29:22 +0800

> with an offset = 0, you get your scheme with MAP.

This doesn't seem convincing to me. You have to reserve something to
avoid well-known ports. Now instead of reserving one port-set id for
an entire address, MAP requires that the left a bits (A (j)) cannot be
zero, i.e., reserve a PORT RANGE in EACH PORT SET.

So I don't think this is the reason to have MAP to support
non-contiguous port set...

---

From: Peng Wu <[email-masked]>
Date: Sat, 20 Oct 2012 14:37:32 +0800

Sorry Woj, but please don't mislead the discussion here.
Softwire approves the separate existance of per-flow stateful
solution, per-subscriber stateful solution and stateless solutions for
IPv4-over-IPv6, at least that's one of the outcomes of the Vancouver
Softwire meeting I participated in.
If you do per-subscriber stateful solution, you provision IPv4 address
and port range explicitly. it's kind of straightforward, right?

---

From: Peng Wu <[email-masked]>
Date: Sat, 20 Oct 2012 15:00:18 +0800

Eliot,

On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear <[email-masked]> wrote:

> This is what we have charters and ADs for.  Did the softwire group exceed
> its charter?  Let's go to the video tape:
>
> I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond
> to.  I will readily state that charters can often cause confusion.  Area
> Directors are responsible for seeing that work occurs in the right place
> within the IETF.
>
For the record, this refers to the DHCPv4-over-IPv6 draft indeed.
The draft was originally submitted to Softwire
http://tools.ietf.org/html/draft-cui-softwire-dhcp-over-tunnel-01
Then during the Quebec meeting last year, the softwire chairs and our AD
who is responsible for both softwire and DHC decided to MOVE this effort TO
DHC because it was decoupled from the softwire solutions and essentially
became a DHC problem.
Therefore we resubmit this document to DHC
http://tools.ietf.org/id/draft-cui-dhc-dhcpv4-over-ipv6-00.txt
And later it was adopted as
http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

So if we are talking about this, please at least respect the history.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 20 Oct 2012 09:13:54 +0200

Peng,

Thanks for the clarification.  Sometimes reading tea leaves is easier
than reading charters and their intents.  Again, however, two ways to do
what is substantially similar in function and identically similar in
purpose should be avoided.  I appreciate Ted's recounting of his
concerns.  And I think he deserves a fair answer to the following

Eliot

On 10/20/12 9:00 AM, Peng Wu wrote:
> Eliot,
>
> On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>        
>     confusion.  Area Directors are responsible for seeing that work
>     occurs in the right place within the IETF. 
>
> Then during the Quebec meeting last year, the softwire chairs and our
> AD who is responsible for both softwire and DHC decided to MOVE this
> effort TO DHC because it was decoupled from the softwire solutions and
> essentially became a DHC problem.

---

From: Peng Wu <[email-masked]>
Date: Sat, 20 Oct 2012 15:40:07 +0800

On Sat, Oct 20, 2012 at 3:13 PM, Eliot Lear <[email-masked]> wrote:

>  Peng,
>
> Thanks for the clarification.  Sometimes reading tea leaves is easier than
> reading charters and their intents.  Again, however, two ways to do what is
> substantially similar in function and identically similar in purpose should
> be avoided.  I appreciate Ted's recounting of his
>
Ironically, no. With the map dhcpv6 option or map , it take the
precondition of embedding ipv4 address and port into ipv6 (in most cases,
which Ole claiming has the ability to assign address, prefix and shared
address). By embedding ipv4 into ipv6, it could appear from the surface
that we are allocating "ipv6" address, so dhcpv6 may fit in from this view.
But Ted has the bigger point that we don't add v4 feature to v6 protocols
which would be useless once v4 disappear.
Then it include a total different case saying that, it could happen when
there is no address embedding, then most of the former stuff doesn't fit.
In this case, we are literrally allocating an ipv4 address, so even it's
over ipv6 network layer, we absolutely need dhcpv4 protocol.

An interesting fact is that with dhcpv4-over-ipv6,theoretically we can do
both...

>> respond to.  I will readily state that charters can often cause confusion.
>> Area Directors are responsible for seeing that work occurs in the right
>> place within the IETF.
>>

---

From: Ole Trøan <[email-masked]>
Date: Sat, 20 Oct 2012 10:50:39 +0200

Peng, Ted,

> Thanks for the clarification.  Sometimes reading tea leaves is easier than reading charters and their intents.  Again, however, two ways to do what is substantially similar in function and identically similar in purpose should be avoided.  I appreciate Ted's recounting of his
> Ironically, no. With the map dhcpv6 option or map , it take the precondition of embedding ipv4 address and port into ipv6 (in most cases, which Ole claiming has the ability to assign address, prefix and shared address). By embedding ipv4 into ipv6, it could appear from the surface that we are allocating "ipv6" address, so dhcpv6 may fit in from this view. But Ted has the bigger point that we don't add v4 feature to v6 protocols which would be useless once v4 disappear.
> Then it include a total different case saying that, it could happen when there is no address embedding, then most of the former stuff doesn't fit. In this case, we are literrally allocating an ipv4 address, so even it's over ipv6 network layer, we absolutely need dhcpv4 protocol.

this is just a corner case of the same mechanism. when no address bits are embedded in IPv6 address, all of the IPv4 address bits and port range bits are in the DHCPv6 option. and what you get is a "configured" point to point IPv4 over IPv6 tunnel with no dependence between the address families.

> An interesting fact is that with dhcpv4-over-ipv6,theoretically we can do both...

by creating an application specific tunnel of IPv4 over IPv6. is _that_ what we want to do?

> concerns.  And I think he deserves a fair answer to the following question, which so far as I can tell is really what the argument is over:
> 
> 

[answering Ted's question here as well]
not sure I grok this question. the mechanism is that a MAP capable CPE includes the MAP option in an ORO option. the DHCPv6 reply contains e.g. the IPv4 address and port range and that IPv4 address and port range is "assigned" to the outside of the NAT44 function. note, that it is not  and MUST NOT be assigned to an interface. so the normal IPv4 allocation mechanism cannot be used.
if this was based on the existing DHCPv4 address option, how would a client know that the above restriction applies?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Oct 2012 15:06:05 +0000

> by creating an application specific tunnel of IPv4 over IPv6. is _that_ what we want to do?

Where is this tunnel of which you speak?

> if this was based on the existing DHCPv4 address option, how would a client know that the above restriction applies?

What allocation mechanism _is_ used?

---

From: Ole Trøan <[email-masked]>
Date: Sat, 20 Oct 2012 18:47:02 +0200

> Where is this tunnel of which you speak?

that is effectively what DHCPv4 over IPv6 is.

> What allocation mechanism _is_ used?

whatever policy the DHCP server has.

can you answer my question please?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Oct 2012 18:13:56 +0000

> that is effectively what DHCPv4 over IPv6 is.

Well, sure, in the same sense that the DHCP relay agent is effectively a tunnel.   But it's consistent with the existing DHCP protocol, and calling it a tunnel is only accurate in the most tortured interpretation of what a tunnel is.   You could also call it a proxy; in fact, though, what it is in DHCP terminology is simply a relay agent.   Using an IPv6 transport for DHC relay is a fairly minor innovation.   Also, the chairs of softwires have informed me that in fact softwires _does_ support the DHCPv4-over-IPv6 work, so this question is moot.

> whatever policy the DHCP server has.

Okay, what policies could a DHCP server have?   Have you documented these policies?

> can you answer my question please?

A DHCPv4 client that supports the port set option has to request it.   If it requests it, that means that it knows not to just use the IP address—it has to do A+P NAT44.   So the _only_ client that can ever get an address and port set pair is one that indicates it knows how to handle it properly.   Other clients would either be configured with a whole IPv4 address, or else would not receive an IPv4 address at all.

---

From: Ole Trøan <[email-masked]>
Date: Sat, 20 Oct 2012 21:53:28 +0200

Ted,

> Well, sure, in the same sense that the DHCP relay agent is effectively a tunnel.   But it's consistent with the existing DHCP protocol, and calling it a tunnel is only accurate in the most tortured…

this work exists within a larger context.
e.g. how does a client know that it should act as a relay?

> Okay, what policies could a DHCP server have?   Have you documented these policies?

what are you asking about? I have no intention of documenting allocation policy. why should the IETF do that?

> A DHCPv4 client that supports the port set option has to request it.   If it requests it, that means that it knows not to just use the IP address—it has to do A+P NAT44.   So the _only_ client that…

so you are saying that based on this option, a DHCPv4 client must act quite differently in how it uses the information in the address option compared to if this option is not present. in the proposed DHCPv6 option, both the port set and the address is within one container option, that is specifically for this purpose. it doesn't give a legacy option a new meaning.

as Eliot suggests I think it is more fruitful to do this discussion IRL.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Oct 2012 21:10:09 +0000

On Oct 20, 2012, at 3:53 PM, Ole Trøan <[email-masked]<mailto:[email-masked]>>
 wrote:
e.g. how does a client know that it should act as a relay?

The DHCPv6 server sends it a DHCPv4-over-IPv6 CRA IPv6 Address option.

This is my point.   You are claiming to provide the functionality of a DHCPv4 server, but your draft leaves that as an exercise for the reader.   IOW, it's not a complete solution.   If the policy happens to be a simple transformation from IPv6 to IPv4 address, then this is probably fine, but it's not solving the same problem that the DHC working group is solving with the DHCPv4-over-IPv6 draft and this draft.

You seem to be stating this as if it is an advantage, but it's not clear to me how that would be so, or even what "legacy option" you are talking about.   Either way:

  *   information is delivered to the device (typically a CPE device) and it sets up an A+P configuration with NAT
  *   it is not easier to do this via DHCPv6 than DHCPv4
  *   doing it via DHCPv6 has implications for the DHCPv6 server that you are addressing with a handwave
  *   placing the burden of implementation on the DHCPv4 client is no worse than placing it on the DHCPv6 client, except that the DHCPv4 client is going away, and the DHCPv6 client is not
  *   placing the burden of implementation on the DHCPv6 server is no better than placing it on the DHCPv4 server, except that the DHCPv4 server is going away, and the DHCPv6 server is not.

So in certain cases, the DHCPv6-based solution will in fact work just fine, with minimal negative impact.   However, the DHCPv4-over-IPv6 solution will work well in all cases, with zero negative impact.   No changes are required anywhere except on the DHCPv4 server and the CPE device (or whatever device is doing A+P).   This is why the DHC working group chose that solution.

We can certainly try to get some clarity on the topic, but the business of the IETF is transacted on the mailing lists, not in person.

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Sat, 20 Oct 2012 21:23:53 +0000

Ted,

The point is to use a high bandwidth medium that is expressly set for such occasions, a f2f meeting. It's not as if one has to wait so long...

Eliot

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Oct 2012 09:03:55 -0400

Le 2012-10-20 17:23, Eliot Lear (elear) a écrit :
> The point is to use a high bandwidth medium that is expressly set for
> such occasions, a f2f meeting. It's not as if one has to wait so long...

I, for one, am keeping myself from replying to this thread precisely 
because it ought to be discussed in Atlanta. I suspect others are doing 
the same...

Simon