Subject: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

From: Dmitry Anipko <[email-masked]>
Date: Tue, 10 Apr 2012 05:18:47 +0000

Hello,

during the WG meeting in Paris, there was a brief discussion around the subject and the authors asked me to take it to the list.

For context: the CRA behavior in section 6 implies that somehow CRA knows 1:1 mapping between server responses, received over IPv6, and IPv4 interfaces where decapsulated DHCPv4 packets should be indicated.  The mechanism how CRA knows that is unclear in case there are multiple IPv4 interfaces on the host.

It would be useful to add text, that discusses whether multiple IPV4 interfaces are in scope, and if they are - what are the possible ways how they can be handled, and what's the recommended way.

If there are multiple ways and all of them are equally preferrable and won't affect interoperability, having such analysis&language would be helpful too.

-Dmitry

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Apr 2012 14:39:40 +0200

In your previous mail you wrote:

> during the WG meeting in Paris, there was a brief discussion around
> the subject and the authors asked me to take it to the list.

=> yes, the authors want to make the I-D ready for a WGLC so
any pending questions are wellcome now.

> For context: the CRA behavior in section 6 implies that somehow CRA
>  knows 1:1 mapping between server responses, received over IPv6, and
>  IPv4 interfaces where decapsulated DHCPv4 packets should be
>  indicated.  The mechanism how CRA knows that is unclear in case
>  there are multiple IPv4 interfaces on the host.

=> as I (too briefly) explained at the meeting this is a question I got
when I wrote the CRA code: I started from a plain DHCPv4/DHCPv6 relay
and I removed all the useless features (e.g., DHCPv6) but when I reached
the multiple interface one I stopped a bit I tried to understand the
consequences: clearly the CRA is too simple to handle multiple interfaces,
for instance there is no way to assign a received answer to an interface.

So the choice was between looking what to add in the CRA spec or looking
whether it could be a problem. Note DHCPv4 clients usually have the
same constraint: a client process manages only one interface and when
a host have multiple interfaces multiple client processes (one per
interface) are used.

According to the DHCPv4 over IPv6 architecture (e.g., the co-location
between client and CRA) a similar solution could be applied: a CRA process
per interface. I checked if this removes any feature: the only constraint
is for the CRA processes to use a different IPv6 address. IMHO this is
a very acceptable constraint.

> It would be useful to add text, that discusses whether multiple IPV4
> interfaces are in scope, and if they are - what are the possible
> ways how they can be handled, and what's the recommended way.

=> it is far better to add a statement explaining the proposed solution
than to make the CRA more complex.

> If there are multiple ways and all of them are equally preferrable
> and won't affect interoperability, having such analysis&language
> would be helpful too.

=> I am afraid I didn't look for another solution (other than to
complexify the CRA). BTW the IPv6 address is used by the server
(TSV or a standard DHCPv4 behind a TSA) to "localize" (i.e., to
associate to a configured link) the client so IMHO other solutions
should make the whole DHCPv4 over IPv6 more complex.

Thanks

[email-masked]

---

From: "Qi Sun" <[email-masked]>
Date: Wed, 11 Apr 2012 21:30:28 +0800

Dear Francis and Dmitry,
    
        As a process of DHCP, it is great to keep it simple rather than to perplex it. Now that there is a same situation in DHCPv4 process, DHCPv4 over IPv6 could use a similar solution, just as Francis stated. Considering multiple-interfaces a special case for the DHCPv4 over IPv6 mechanism, IMHO a more proper way is to make it clear in the draft with one solution.

Best Regards!

Qi Sun

From: Francis Dupont
Date: 2012-04-11 20:39
To: Dmitry Anipko
CC: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

Thanks

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

---

From: Peng Wu <[email-masked]>
Date: Wed, 11 Apr 2012 23:22:12 +0800

Hi Francis & Dmitry,

Francis's proposal is one option. The CRA per-interface is reasonable.
I see RFC6334 made some similar assumption.
The cost is different addresses for different CRAs, the gain is we
made DHCP client clean.

Another proposal(by Ted) is to use client ID options for different interfaces.
This way DHCP mssages for different interfaces can be identified.
The cost is that we may need a little intellegence in the client.

So if we *have to* put some text on this subject in the draft, we
could go simply like:
 "A CRA SHOULD serve only one IPv4 interface. If it has to serve
multiple interfaces, different client ID MUST be used to identify
different interfaces"
Agree?

Now my concern is whether we should put the texts into the draft.
If we put it there, we add a guidence on this specific issue; if not,
we keep the draft clean.

// For the other guys, to eliminate the confusion, in typical scenario
the IPv4 interfaces we talking about would be tunnel interfaces.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 Apr 2012 00:18:04 +0200

>  I see RFC6334 made some similar assumption.

=> any RFC about a client function makes this assumption.

>  Another proposal(by Ted) is to use client ID options for different interfaces.

=> usually it is not require as different interfaces should have different MAC
addresses (yes, I know it is not universally true, so the "usually").

>  multiple interfaces, different client ID MUST be used to identify

=> I disagree because the text is partly about CRA and partly about client,
so the clarification is very confusing.

>  If we put it there, we add a guidence on this specific issue; if not,

=> IMHO a remark about the fact a CRA process can serve only one interface is enough.

>  //0For the other guys, to eliminate the confusion, in typical scenario

=> anyway the idea to use DHCP to configure directly virtual (vs physical) interfaces
is BAD (and doesn't work, so please don't try to fix it :-).

Regards

PS: I put DHCP because DHCPv6 is only marginally better (less worse if you prefer).

---

From: Peng Wu <[email-masked]>
Date: Thu, 12 Apr 2012 16:17:08 +0800

Francis,

> addresses (yes, I know it is not universally true, so the "usually").
That's the exact reason we write it down in the draft, right?
And it's easy to satisfy, considering the requirement we address.

> so the clarification is very confusing.
I can make it more precise, I was just proposing the general idea.
How about  "A CRA SHOULD serve only one IPv4 interface. If it has to
serve multiple interfaces, DHCP client(s) MUST use different client ID
for different interfaces, to distinguish DHCP messages from the CRA"

> is BAD (and doesn't work, so please don't try to fix it :-).
I may have caused some confusion because of the other offline
mail I sent to you. We don't have the assumption of multiple DHCP
clients on multiple VIFs here. In fact we'd better not touch this in
the draft, aka leave it open.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 Apr 2012 13:32:46 +0200

In your previous mail you wrote:

>  > => usually it is not required as different interfaces should have
>  > different MAC addresses (yes, I know it is not universally true,
>  > so the "usually").
>

=> I can't see the reason: IMHO it is just over specified and
out of scope.

>  And it's easy to satisfy, considering the requirement we address.

=> this is not the question.

>  > => I disagree because the text is partly about CRA and partly
>  > about client, so the clarification is very confusing.
>

=> worse: the MUST is both bogus (as I explained before) and
out of scope (because it is about the client).
IMHO if you want to keep something it should be:
"A CRA serves only one interface."
no SHOULD because it is a fact, no IPv4 because an interface is not
a network layer only object.

But if the definition of a CRA/LCRA is accurate this should be a
direct consequence of the definition. So I suggest to reread the
definition and to improve it if needed.

And please note the client ID doesn't help: the CRA has still
no way to know where is the client without keeping state, so
I think this solution is just a variant of making the CRA more
complex: I'd like to see it rejected. (and I don't understand
why we are discussing about this: you are losing my time).

Regards

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Apr 2012 12:52:52 +0000

On Apr 12, 2012, at 7:32 AM, Francis Dupont <[email-masked]<mailto:[email-masked]>> wrote:
the CRA has still
no way to know where is the client without keeping state

Not so--it just broadcasts.   Every client hears the response, one client selects it.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Apr 2012 10:52:20 +0200

In your previous mail you wrote:

> the CRA has still no way to know where is the client without keeping
>  state

>  Not so--it just broadcasts.

=> on which link?

>  Every client hears the response, one client selects it.

=> this works only when the CRA (LCRA) serves only one link,
so today we have only two modes: CRA aka co-located, LCRA aka on link,
but nothing for the multi-interface served by one CRA instance.
(but it is not a problem as it can be handled by one instance per link
so for me this issue is solved/closed).

Thanks

---

From: Peng Wu <[email-masked]>
Date: Sat, 14 Apr 2012 15:24:03 +0800

Francis,

Francis,

I was going to make my cocern on this clear, but seems we still have
confusion. Let' settle this first.

One CRA per-link is fine. I think we all agree.
We're talking about the case where there is ONLY ONE link, but
multiple tunnel endpoints on the host, relying on the SAME link as
well as the SAME CRA. It's still per-link CRA (BTW, LCRA is not
currently discussed).

I know from Softwire perspective, this multiple tunnel on same link
might seem no use cas. But the draft is a pure DHC document now so
we'd better be very rigorous. Theoretically that could happen.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 14 Apr 2012 22:10:52 +0200

In your previous mail you wrote:

>  multiple tunnel endpoints on the host,

=> I am confused: either the tunnels are links (it is a bad idea IMHO
but it is not a priori impossible), or they are not links and they
don't exist for DHCP.

>  relying on the SAME link as

=> you are clearly in the one link case so I can't see a problem.

>  I know from Softwire perspective, this multiple tunnel on same link

=> multiple tunnel on same link has no meaning, in particular
with DHCP which is defined for physical interfaces (so links).

>  we'd better be very rigorous. Theoretically that could happen.

=> multiple interface is possible but it means more than one link.

IMHO the confusion comes from the bad idea to use DHCP to assign
addresses to virtual interfaces like tunnels. If you use DHCP
only for physical interfaces, it could work even with the DHCPv4
over IPv6 transport variant.

Thanks

PS: I reread the last version and I have some comments about it.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Apr 2012 22:53:06 +0000

On Apr 14, 2012, at 4:10 PM, Francis Dupont <[email-masked]<mailto:[email-masked]>> wrote:
I am confused: either the tunnels are links (it is a bad idea IMHO
but it is not a priori impossible), or they are not links and they
don't exist for DHCP.

That is not the use case for this draft.   The use case for this draft is that a client wants IPv4 support on an IPv6-only network, and so it uses DHCP to get an address for the tunnel endpoint.   It does this by broadcasting a DHCPv4 request on the local interface, which the CRA captures and forwards to the DHCPv4 server over IPv6.   Once the tunnel is established, renewals are (one assumes) routed down the tunnel.   But the idea, as I understand it at least, is to leverage the existing DHCPv4 client, not to require a special DHCPv4 client.   If we require a special DHCPv4 client, we might as well just do all the DHCPv4 transactions over UDPv6.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 15 Apr 2012 12:21:22 +0200

In your previous mail you wrote:

>  On Apr 14, 2012, at 4:10 PM, Francis Dupont wrote:
> That is not the use case for this draft.  The use case for this
> draft is that a client wants IPv4 support on an IPv6-only network,
> and so it uses DHCP to get an address for the tunnel endpoint.

=> IMHO some of the confusion comes from this term "tunnel endpoint":
it is both the node at this end of the tunnel and the virtual interface
of the tunnel.

> It does this by broadcasting a DHCPv4 request on the local
> interface, which the CRA captures and forwards to the DHCPv4 server
> over IPv6.

=> this is the first interpretation and the local interface is the
physical interface used by the tunnel endpoint node to send encapsulated
packets to the tunnel other end.

> Once the tunnel is established, renewals are (one assumes) routed
> down the tunnel.

=> in fact to work well either the server has to handle both the TSV
function and the regular DHCPv4 over a tunnel, or a TRA is at the
tunnel other end. But this doesn't change the client/CRA so is a side
comment.

> But the idea, as I understand it at least, is to leverage the
> existing DHCPv4 client, not to require a special DHCPv4 client.

=> yes, this is the idea. And I tried with two very different and
unmodified clients so the idea is valid. Note it is not fully true
for the server side (even the I-D says it is).

> If we require a special DHCPv4 client, we might aswell just do all
> the DHCPv4 transactions over UDPv6.

=> I agree: on the client side the DHCPv4 client is unmodified and
the CRA is as simple as possible. IMHO these are critical for the
target deployment, i.e., low cost CPEs.

Thanks

---

From: Peng Wu <[email-masked]>
Date: Mon, 16 Apr 2012 18:25:37 +0800

Francis,

> tunnel other end. But this doesn't change the client/CRA so is a side
The server could have native IPv4 access, used for receiving unicast
message to server id.
If we want to address this, we could add a RECOMMANDED setense.

> target deployment, i.e., low cost CPEs.
I agree this is critical. The only case we may break that is if we
want to solve the problem in this thread when multiple CRAs with
different addresses is unavailable.
The reason I insist on the DHCP client for multiple tunnel endpoints
with client IDs is because we would leave a question mark in the draft
if we raise this problem but only mandate the multiple CRA
solution(i.e., what if multiple v6 address unavailable)

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Apr 2012 14:09:00 +0200

>  The server could have native IPv4 access, used for receiving unicast

=> according to my experiments it works only with a physical interface
where renews are received, so it can put a constraint on the topology.
But I tried only one server and not very hard.

>  If we want to address this, we could add a RECOMMANDED setense.

=> RECOMMENDED sentense? Today I am fine with the current wording
even I know it won't be always followed in the real world
(but the non-compliance is with RFC 2131 so please keep the can of
worms closed :-).

>  different addresses is unavailable.

=> different addresses in IPv6 is pretty unlikely, even without
multi-interface, so IMHO it is a problem which doesn't need to
be addressed.

>  with client IDs

=> if endpoint stands for a node then there is one client with one
interface, so no issue.  If it stands for an interface please don't
try to assign addresses to virtual interfaces using DHCP.

>  ... is because we would leave a question mark in the draft
>  solution (i.e., what if multiple v6 address unavailable)

=> I am not even convinced whether we should have a word about the
problem, so of course I strongly object to put more.

Regards

PS: I have the draft with some editorial comments in front of me.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 18 Apr 2012 03:14:16 +0000

>> It does this by broadcasting a DHCPv4 request on the local interface, which the CRA captures and forwards to the DHCPv4 server over IPv6.   Once the tunnel is established, renewals are (one assumes) routed down the tunnel.

What section of the I-D describes that only the original request goes over CRA, while renewals are routed to the tunnel?

From: Ted Lemon [mailto:[email-masked]]
Sent: Saturday, April 14, 2012 3:53 PM
To: Francis Dupont
Cc: Peng Wu; [email-masked]; Dmitry Anipko
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 18 Apr 2012 04:09:01 +0000

Peng, it seemed to me at some point there was a consensus between Francis & you regarding adding clarification that CRA serves only one tunnel interface and requires a dedicated 4over6 IPv6 address. If that's the case, can such clarification be added to the CRA definition?

IMO, that would address the question from the prospective of this I-D. There would be still question for draft-ietf-softwire-public-4over6, whether scenario with multiple 4over6 IPv6 addresses on the same IPv6 interface are supported, and if yes - how are they provisioned. 

draft-ietf-softwire-public-4over6 could also declare such scenario out of scope - but having CRA definition clarification in draft-ietf-dhc-dhcpv4-over-ipv6 is still useful, because then draft-ietf-dhc-dhcpv4-over-ipv6 would not have to change in future should draft-ietf-softwire-public-4over6 define some method for allocation of multiple 4over6 IPv6 addresses.

-Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Monday, April 16, 2012 5:09 AM
To: Peng Wu
Cc: [email-masked]; Ted Lemon; Dmitry Anipko
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

Regards

---

From: Peng Wu <[email-masked]>
Date: Wed, 18 Apr 2012 13:02:04 +0800

That would be a result of the server id related texts in section 7.
"When filling in the server id option of DHCP replies, the TSV MUST
choose an IPv4 address which is reachable from the client once the
residual IPv4 serivice is set up."

2012/4/18 Dmitry Anipko <[email-masked]>:
>>> It does this by broadcasting a DHCPv4 request on the local interface,
>>> which the CRA captures and forwards to the DHCPv4 server over IPv6.   Once
>>> the tunnel is established, renewals are (one assumes) routed down the
>>> tunnel.
>
>
>
> What section of the I-D describes that only the original request goes over
> CRA, while renewals are routed to the tunnel?
>
>
>
> On Apr 14, 2012, at 4:10 PM, Francis Dupont <[email-masked]>
> wrote:
>
> That is not the use case for this draft.   The use case for this draft is
> that a client wants IPv4 support on an IPv6-only network, and so it uses
> DHCP to get an address for the tunnel endpoint.   It does this by
> broadcasting a DHCPv4 request on the local interface, which the CRA captures
> and forwards to the DHCPv4 server over IPv6.   Once the tunnel is
> established, renewals are (one assumes) routed down the tunnel.   But the
> idea, as I understand it at least, is to leverage the existing DHCPv4
> client, not to require a special DHCPv4 client.   If we require a special
> DHCPv4 client, we might as well just do all the DHCPv4 transactions over
> UDPv6.
>
>

---

From: Peng Wu <[email-masked]>
Date: Wed, 18 Apr 2012 13:31:15 +0800

Dimitry,

> Peng, it seemed to me at some point there was a consensus between Francis & you regarding adding clarification that CRA serves only one tunnel interface and requires a dedicated 4over6 IPv6 address…

[Peng]I think we all agree that's the recommanded case.
Ted wrote some texts about the solution of modified client with
multiple client ID & multiple state machines, to serve mutliple tunnel
interfaces (or let's say, to manage  multiple address retrieving).
It's a detailed description of the corresponding solution discussed in
this thread. From technical perspective it can work. The divergence
now is, whether to include it in the draft. What's your opinion?

> IMO, that would address the question from the prospective of this I-D. There would be still question for draft-ietf-softwire-public-4over6, whether scenario with multiple 4over6 IPv6 addresses on t…
[Peng] In public 4over6, we assume there is only one tunnel on the
initiator(as is the same with other 4-over-6 mechanisms).  And, if the
initiator retrieve the address through DHCP, there would be only one
IPv4 address. That's not different from regular DHCP. The problem we
have in this thread is caused by multiple tunnel on the device.
Thanks for bring it up. I'll state that the 4over6 initiator only run
one tunnel/public 4over6 instance in the possible revision.

> draft-ietf-softwire-public-4over6 could also declare such scenario out of scope - but having CRA definition clarification in draft-ietf-dhc-dhcpv4-over-ipv6 is still useful, because then draft-ietf…
[Peng]I agree.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 18 Apr 2012 09:50:16 +0200

In your previous mail you wrote:

> >> interface, which the CRA captures and forwards to the DHCPv4
> >> server over IPv6.  Once the tunnel is established, renewals are
> >> (one assumes) routed down the tunnel.
>
> What section of the I-D describes that only the original request
> goes over CRA, while renewals are routed to the tunnel?

=> none in the I-D but it is the way DHCPv6 works according to RFC
2131, and the text about the DHCPv4 client which stays unmodified.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 18 Apr 2012 09:58:46 +0200

In your previous mail you wrote:

>  Peng, it seemed to me at some point there was a consensus between
>  Francis & you regarding adding clarification that CRA serves only
>  one tunnel interface

=> no, it serves at most the physical link where tunnel interfaces are
seated.

Regards

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Apr 2012 12:48:48 +0000

On Apr 17, 2012, at 11:14 PM, Dmitry Anipko <[email-masked]<mailto:[email-masked]>> wrote:
What section of the I-D describes that only the original request goes over CRA, while renewals are routed to the tunnel?

I don't think that's ever stated.   That's just how DHCP works—broadcast messages are relayed; unicast messages are routed.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 18 Apr 2012 22:21:52 +0000

Per the definitions in the latest draft:

"Client Relay Agent(CRA) - sits on the same, IPv6-accessable host with the DHCPv4 client"

" (LCRA): a CRA sits on the link of the host rather then inside the host".

I specifically was referring to this CRA definition, where CRA serves the DHCPv4 client of the host (and that DHCPv4, I assumed, acts on a tunnel interface). 

If you want the proposed definition to read as "CRA can serve no more than one tunnel interface", while "LCRA can serve no more than one link", that's fine with me.

-Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2012 12:59 AM
To: Dmitry Anipko
Cc: Peng Wu; [email-masked]; Ted Lemon
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces 

Regards

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 19 Apr 2012 04:59:07 +0000

>> From technical perspective it can work. The divergence

If client-ids is something that is currently not widely implemented in existing DHCP clients, I'm not sure that inclusion of this option in the text would be practically useful at this time. And then, if it is easier to reach agreement without including this option, I'd say don't include it.

-----Original Message-----
From: Peng Wu [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 10:31 PM
To: Dmitry Anipko
Cc: Francis Dupont; [email-masked]; Ted Lemon
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

Dimitry,

[Peng]I agree.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Apr 2012 13:48:42 +0000

On Apr 19, 2012, at 12:59 AM, Dmitry Anipko <[email-masked]<mailto:[email-masked]>> wrote:
If client-ids is something that is currently not widely implemented in existing DHCP clients, I'm not sure that inclusion of this option in the text would be practically useful at this time. And then, if it is easier to reach agreement without including this option, I'd say don't include it.

In order for a client to configure multiple tunnel endpoints using the same CRA, there is _no choice_ but to use different client identifiers.   That is to say, there is _no choice_ but to modify the client.   So specifying the client identifier is okay.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 20 Apr 2012 02:55:36 +0000

>>In order for a client to configure multiple tunnel endpoints using the same CRA

My reading of Peng's question was as to whether a specific requirement (same CRA used by multiple tunnel endpoints) and a solution addressing this requirement shall be included in the text, and I commented on that question.

As I understand, your comment rather relates to "assuming this specific requirement (same CRA used by multiple tunnel endpoints) must be included in the text, what the solution is". That's a different question, which only appears if there is a requirement for same CRA to serve multiple tunnel endpoints (as opposed to e.g. having per tunnel endpoint CRA). Are there reasons to have that as a requirement?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, April 19, 2012 6:49 AM
To: Dmitry Anipko
Cc: [email-masked]; Francis Dupont
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Apr 2012 03:35:07 +0000

On Apr 19, 2012, at 10:55 PM, Dmitry Anipko <[email-masked]<mailto:[email-masked]>>
 wrote:
That’s a different question, which only appears if there is a requirement for same CRA to serve multiple tunnel endpoints (as opposed to e.g. having per tunnel endpoint CRA). Are there reasons to have that as a requirement?

I don't think so, no.   The suggestion that there should be such a requirement was raised by someone else; I thought it was you, but maybe you were just raising a question that had been raised by someone else in softwires?

---

From: Peng Wu <[email-masked]>
Date: Fri, 20 Apr 2012 17:52:35 +0800

Dmitry,

> As I understand, your comment rather relates to “assuming this specific
> requirement (same CRA used by multiple tunnel endpoints) must be included in
> the text, what the solution is”. That’s a different question, which only
> appears if there is a requirement for same CRA to serve multiple tunnel
> endpoints (as opposed to e.g. having per tunnel endpoint CRA). Are there
> reasons to have that as a requirement?
I think it somehow reflects your original concern. Because in some
cases we cannot simply require multiple IPv6 addresses to satisfy
multiple CRAs.
BTW, I think about this again and find that , even if we can require
multiple IPv6 addresses since all the DHCP messages are broadcasted on
the same link, we may still require different client IDs to clarify
which CRA to serve which messages. So it's really about request
multiple addresses through ONE link with broadcast.

My answer to this is, from Softwire perspective, we currently don't
have use case for that. One tunnel, one CRA, one client, that's all.
>From DHC perspective, it's reasonable to raise the doubt that, now
that a relay is put inside the host, and if the host have multiple
tunnels which requires one IPv4 address each, how does the relay
behave ( as you've raised in Paris).

About the solution, I'm starting to think that AS LONG AS we require
multiple IPv4 addresses on ONE link with broadcast, we need multiple
client IDs. If we have a *one-for-all* client runs on the physical
interface, it will need multiple state machines. If we have multiple
clients run on different VIFs (which Francis emphasised is not a good
idea), we need some extra implementation effort to achieve the message
"transmission" between the VIF and the physical interface. In the
first case, multiple CRAs won't help; in the second case, the message
can be "transmitted" to different CRAs directly inside the host, so we
won't need the aid from client id (at the cost of extra
implemenation).

What do you guys think?
If we settle this, I think we should make a fast revision (Francis has
aleady raised some review inputs on the other thread) and try to
request WGLC.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 20 Apr 2012 21:40:24 +0000

>> The suggestion that there should be such a requirement was raised by someone else

Sorry if there was miscommunication, that's not what I meant. My comment on the list (and I believe, at the meeting) was: "... discusses whether multiple IPV4 interfaces are in scope, and if they are - what are the possible ways how they can be handled, and what's the recommended way.". 

Having single CRA to serve multiple tunnel interfaces is one way to handle such scenario, but may be not the only one, and it is also possible to declare scenario not supported/out of scope. 

All I meant to say, if I didn't communicate clearly, was that the current draft is not fully clear about what's supported in this case, and if something is supported, how an implementation should support it in terms of CRA/tunnel mapping.  E.g. if the authors prefer to declare scenario out of scope, and implementers are fine with it, I think that's a fine option.

From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, April 19, 2012 8:35 PM
To: Dmitry Anipko
Cc: [email-masked]; Francis Dupont
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

On Apr 19, 2012, at 10:55 PM, Dmitry Anipko <[email-masked]>
 wrote:
That's a different question, which only appears if there is a requirement for same CRA to serve multiple tunnel endpoints (as opposed to e.g. having per tunnel endpoint CRA). Are there reasons to have that as a requirement?

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 30 Apr 2012 06:02:02 +0000

>> My answer to this is, from Softwire perspective, we currently don't have use case for that. One tunnel, one CRA, one client, that's all.

If there is no scenario for multiple tunnels, then I think it would be fine to just say that and that the only supported configuration is with one CRA and one tunnel interface per host. 

In my opinion, having such addition would help to avoid different implementations for the multiple interfaces case, which actually would not be interoperable with one another.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peng Wu
Sent: Friday, April 20, 2012 2:53 AM
To: Dmitry Anipko
Cc: [email-masked]; Francis Dupont; Ted Lemon
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

Dmitry,

> As I understand, your comment rather relates to "assuming this specific
> the text, what the solution is". That's a different question, which only

What do you guys think?

---

From: Peng Wu <[email-masked]>
Date: Tue, 1 May 2012 00:20:27 +0800

Dmitry,

On Monday, April 30, 2012, Dmitry Anipko wrote:

> If there is no scenario for multiple tunnels, then I think it would be
> fine to just say that and that the only supported configuration is with one
> CRA and one tunnel interface per host.
>
> In my opinion, having such addition would help to avoid different
> implementations for the multiple interfaces case, which actually would not
> be interoperable with one another

 I agree with you.
I propose we keep one CRA and one tunnel per host as the default case in
the draft, and put an appendix section to discuss the multi tunnel case. In
this way we can be precise on this issue.
I'll come up with a new version soon to address this. Thanks.