Subject: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 13:31:21 +0200

I've just posted a one pager on how I think DHCPv4 over IPv4 over IPv6 tunnels can work.
this is the solution "DHCPv4oSW" in http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-01

I wrote this largely for myself to try to understand why we couldn't run DHCPv4 over the tunnel
just like any other link-layer.

please let me know what I've missed.

cheers,
Ole

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt
> Date: June 12, 2013 13:25:04 GMT+02:00
> To: Ole Troan <[email-masked]>
> Message-Id: <[email-masked]>
> 
> 
> A new version of I-D, draft-troan-dhc-dhcpv4osw-00.txt
> has been successfully submitted by Ole Troan and posted to the
> IETF repository.
> 
> Filename:	 draft-troan-dhc-dhcpv4osw
> Revision:	 00
> Title:		 DHCPv4 over A+P softwires
> Creation date:	 2013-06-12
> Group:		 Individual Submission
> Number of pages: 4
> URL:             http://www.ietf.org/internet-drafts/draft-troan-dhc-dhcpv4osw-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-troan-dhc-dhcpv4osw
> Htmlized:        http://tools.ietf.org/html/draft-troan-dhc-dhcpv4osw-00
> 
> 
> Abstract:
>   A node getting IPv4 access via an A+P mechanism might need other IPv4
>   configuration information.  This memo describes how DHCPv4 is
>   supported, on IPv4 over IPv6 tunnels with shared IPv4 addresses.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2013 12:38:58 +0000

A few obvious things:

- You should note that DHCP servers need to be modified to return packets to the source port rather than the port defined in RFC2131, bearing in mind the complication that DHCP servers return packets to a different port depending on whether they think they are talking to a relay or a client.   An existing DHCP server will always return the DHCP packet to port 68 if it's a direct communication to the client, regardless of the source port the client used, and may indeed drop DHCP packets with bogus source ports.
- Is it in fact the case that IPv4-in-IPv6 tunnels will work before the CE IPv4 address is known?
- Does the BR have a way to tell over which tunnel a packet arrived, in the case that the unspecified address is used?   What does it use to identify the tunnel in option 82—a new option containing the IPv6 address of the CE tunnel endpoint?
- DHCP often uses option 82 to determine information about the client; does the BR need to act as an L2 relay in the case that the client unicasts its request to the DHCP server?

I guess the main reaction I have to this document is disquiet.   RFC2131 was issued before the IETF got really serious about normative language and consistency, and it has some inconsistencies that have never been resolved, _particularly_ with regard to the handling of DHCPINFORM and unicast exchanges with the DHCP server.   There is a lot of existing practice that is not documented anywhere.   The best I can say about what you are proposing here is that the behavior of the agents on the network is likely to be unpredictable, because you are building this on a foundation of sand.

Weirdly, I think that both DHCPv4overIPv6 and DHCPv4overDHCPv6 have the virtue of being so _different_ in their underlying transport that these issues don't arise: the complete path from the client to the server has to be re-specified and re-implemented, and there's no possibility of code reuse, so no possibility that the reused code will have unexpected behaviors.

I think writing this up is a useful effort, but getting this to the point where it is really solid and accounts for all the edge cases is going to be a lot of work—it's vastly underspecified at the moment, as I'm sure you're aware.   Is it really worth the working group's time to go through the effort of making this into a solid document?

---

From: <[email-masked]>
Date: Wed, 12 Jun 2013 14:43:49 +0200

Hi Ole,

Thanks for writing that one up. A few observations:

1, From a BR implementation perspective, this changes the forwarding logic
a little: I.e. If there is a valid MAP rule for the packet then forward,
if there is no valid MAP rule and the encapsulated SRC is 0.0.0.0/port 67
then relay else drop. Does this cause any implementation problems?

2, The DHCP client will need to reconfigure the port that it is working on
dynamically throughout its lifecycle. I.e: the initial allocation process
is sourced from port 67, but then it needs to reconfigure itself to be
sourced from a valid port allocated to the client. This may change

3, One thing that I think needs to be considered - If the client
successfully gets configured, then the BR forwarding is broken - I.e there
is no corresponding MAP rule in the BR based on the dynamic address
allocation that the BR has relayed. This needs to be considered as part of
this as even unicast based renew messages necessary for maintaining the
lease don't work.

The obvious way that this would be resolved is that the BR would
dynamically build its mapping rules based on snooping the contents of the
DHCP responses from the server. There is an additional consideration about
spoofing DHCP replies and DOSing the BR in this case.

4, One technical clarification on page 2 -

A DHCPv4 client communicates directly with the DHCPv4 server after it
   has acquired addresses.  That requires that the DHCPv4 server
supports clients using a different UDP port than 68.

Surely, this should be port 67?

5, I'm not sure if you're advocating that this is the best way to tackle
the config problem or if it's just fleshing out the solution so that it
can be properly considered within draft-ietf-dhc-v4configuration (without
changing the published conclusion).

Cheers,
Ian

On 12/06/2013 13:31, "Ole Troan" <[email-masked]> wrote:

>this is the solution "DHCPv4oSW" in
>http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-01
>
>> URL:            
>>http://www.ietf.org/internet-drafts/draft-troan-dhc-dhcpv4osw-00.txt
>> Status:         
>>http://datatracker.ietf.org/doc/draft-troan-dhc-dhcpv4osw
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 15:25:39 +0200

Ted,

thanks for the expedient review! 

> - You should note that DHCP servers need to be modified to return packets to the source port rather than the port defined in RFC2131, bearing in mind the complication that DHCP servers return packe…

yes, the draft says:
   "A DHCPv4 client communicates directly with the DHCPv4 server after it
   has acquired addresses.  That requires that the DHCPv4 server
   supports clients using a different UDP port than 68."

> - Is it in fact the case that IPv4-in-IPv6 tunnels will work before the CE IPv4 address is known?

I can't think of a reason why they wouldn't work.

> - Does the BR have a way to tell over which tunnel a packet arrived, in the case that the unspecified address is used?   What does it use to identify the tunnel in option 82—a new option containing…

yes. and probably also the source UDP port.

> - DHCP often uses option 82 to determine information about the client; does the BR need to act as an L2 relay in the case that the client unicasts its request to the DHCP server?

I wouldn't think so. given a port aware DHCPv4 server, then DHCP can run directly between client and server, as soon as the initial bootstrap is done.

> I guess the main reaction I have to this document is disquiet.   RFC2131 was issued before the IETF got really serious about normative language and consistency, and it has some inconsistencies that…

good to know! ;-)

> Weirdly, I think that both DHCPv4overIPv6 and DHCPv4overDHCPv6 have the virtue of being so _different_ in their underlying transport that these issues don't arise: the complete path from the client…

that's also the argument against these mechanisms, that they are essentially new protocols.
do we really have to spend so much time and resources to support sunsetting of IPv4? should we?

> I think writing this up is a useful effort, but getting this to the point where it is really solid and accounts for all the edge cases is going to be a lot of work—it's vastly underspecified at the…

the benefits of this is that it is well understood, and with regards to your concerns about building on sand.
it is a reasonably closed and controlled environment. the DHCPv4 client runs on a CPE (that will have to be updated for this), the relay and server runs under the control of the ISP. and all of those needs to be touched and tested for this.

it isn't like you can connect an unsuspecting DHCP client here (well, I'm sure you can... ;-))

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 15:35:13 +0200

Ian,

> then relay else drop. Does this cause any implementation problems?

I haven't looked at the code, but it is in theory no different than the normal UDP helper.

> sourced from a valid port allocated to the client. This may change

yes, the port will change.
the source port must be in the DHCP binding.

> this as even unicast based renew messages necessary for maintaining the

yes, but this is no different than the DHCP server giving out an address to a client, which there
is no routing for in the network. configuration error. don't do it. ;-)

> spoofing DHCP replies and DOSing the BR in this case.

yes, in this case snooping could definitely work.

> Surely, this should be port 67?

doesn't the client use source port 68?
so that source port has to be allocated from the port range. while the well-known server port can stay unchanged
and fixed at 67.

> changing the published conclusion).

I'm not either. I'm probably mostly advocating that only DHCPv6 should be used, and all services that otherwise would
need IPv4 configuration information should run on IPv6. but then I'm known to be disconnected from reality too. ;-)

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 15:37:05 +0200

Branimir,

> I sam Ted and Ian already posted some comments, but I have an additional one:
> 
> If the BR works in DHCP relay mode, at the initial communication it will have to check if the source UDP port is 68 (given the source address is 0.0.0.0) and perform the relaying function. This is basically DPI and would have to be implemented in hardware for it to work efficiently... If you work in an virtualized environment, I expect it would slow down the BR.
> 
> This is an observation which I think would be worthwhile to include in the draft - comparing to other approaches, the BR will either be more expensive or lacking in performance.

absolutely correct. I didn't include it, since that's how all DHCP relays work today on other link-layers too.

you may argue the finer point that listening to broadcast for a packet to yourself isn't DPI. ;-)

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2013 13:57:12 +0000

> I can't think of a reason why they wouldn't work.

Essentially now you have a half-built tunnel that works one way when you don't have an IP address, and possibly a different way when you do.  Where is the RFC that describes how this tunnel works?   Suppose I send an IP address down the tunnel with a destination of 255.255.255.255: how does the routing for that packet work?   It's certainly true that we can intuit how it ought to work, but the question is, is there a specification that says how it works, or are you relying on the implementor's intuition?

> do we really have to spend so much time and resources to support sunsetting of IPv4? should we?

This is an argument in favor of dropping all the work softwire is currently doing, and has done.  Stateless 4over6 and DSlite both require substantial implementation work for what is essentially a temporary technology.

Furthermore, either you are reusing existing technology with dhcpv4osw, or you are writing a new protocol.   If you are reusing existing technology, then the argument that you are building this on a foundation of sand applies.   If you are writing a new protocol, then the argument you raise above does not apply, because dhcpv4osw is notionally exactly the same as the other two alternatives, only much more complicated to specify because it isn't using IPv6 as a transport—it's using an IPv4 tunnel in a half-configured state.

So again, why are you wasting the working group's time on this?   If this is really just for your information, can we please drop it now?   If you are seriously proposing reopening the debate about how to do DHCPv4 over a native IPv6 network, a debate which I _thought_ we'd settled in Orlando, can you explain why you think it's worth the working group's time to revisit this issue?

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 16:09:12 +0200

Ted,

> Essentially now you have a half-built tunnel that works one way when you don't have an IP address, and possibly a different way when you do.  Where is the RFC that describes how this tunnel works?…

hmm, not sure I get the point. if you connect an IPv4 host to an Ethernet link, then that client sends a packet with an unspecified source and 255.255.255.255 as destination. how 'routing' is done for that client, isn't that the same problem?
and no, routing (as in forwarding) isn't done, that's why there is a relay there.

> This is an argument in favor of dropping all the work softwire is currently doing, and has done.  Stateless 4over6 and DSlite both require substantial implementation work for what is essentially a…

yep.

> Furthermore, either you are reusing existing technology with dhcpv4osw, or you are writing a new protocol.   If you are reusing existing technology, then the argument that you are building this on…

no, the tunnel isn't in a half configured state, just as an Ethernet isn't in a half configured state before IPv4 address is assigned.
the L2 is up.

> So again, why are you wasting the working group's time on this?   If this is really just for your information, can we please drop it now?   If you are seriously proposing reopening the debate about…

I object to your use of language. if you feel this is a waste of time, then stop engaging in the debate.

I'm reopening the debate, because I don't think we have explored what appears to me to be the obvious and simple solution,
and I'm somewhat puzzled that we are exploring building new protocols for a problem that is already solved, and should
hopefully have a short lifetime.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2013 14:24:46 +0000

> and no, routing (as in forwarding) isn't done, that's why there is a relay there.

I would expect that a naive tunnel implementation that wasn't specifically addressed to this use case would drop the packet, because it's not to a valid destination.

> no, the tunnel isn't in a half configured state, just as an Ethernet isn't in a half configured state before IPv4 address is assigned.

I think you are splitting hairs.   If you wanted to configure a tunnel of this type on your OpenWRT router, today, what would you type at the shell prompt?

> I object to your use of language. if you feel this is a waste of time, then stop engaging in the debate.

I can't, because you've re-raised it, even though it was settled in Orlando after a huge amount of wasted time prior to Orlando.   Object to my language all you want, but this is a trivial issue that does not need further debate.

> hopefully have a short lifetime.

The problem is not already solved: the solution you are proposing requires changes on DHCP servers, DHCP clients, DHCP relay agents and probably stack changes as well to support the tunnel functionality your solution requires.   It requires new infrastructure that doesn't already exist.   It requires tunnel functionality that is not documented in any RFC (I assume your failure to list an RFC confirms this).   It requires detailed specification, rather than simple specification, in order to (we would hope) catch all the edge cases that are underspecified in existing documents.

You and I went over this in painful detail in a long private email exchange at the end of the IETF meeting in Atlanta.   So I'm sorry if it seems to you that I am being unkind in my use of language, but your claim that this really needs to be explored and that you are not wasting the working group's time by raising it yet again does not match with the history of this discussion.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 23:05:02 +0200

Ted,

> I think you are splitting hairs.   If you wanted to configure a tunnel of this type on your OpenWRT router, today, what would you type at the shell prompt?

I think you are digressing.

if you want evidence of how existing implementations work, I did set up the equivalent of draft-ietf-softwire-public-4over6-09 in IOS.
(which is the same as MAP 1:1 with separate provisioning. which is the same as an RFC2473 tunnel with DHCPV4 over it, or the same as LW46 in full address sharing mode.)

CE === BR ---- DHCPv4 server

manually configured RFC2473 tunnel with DHCPv4 over it.

CE:
interface Ethernet0/0
 ipv6 address 1::2/64
interface Tunnel0
 ip address dhcp
 tunnel source Ethernet0/0
 tunnel mode ipv6
 tunnel destination 1::1

BR:
interface Ethernet0/0
 ipv6 address 1::1/64
interface Ethernet0/1
 ip address 1.1.1.2 255.255.255.0
interface Tunnel0
 ip address 2.2.2.2 255.255.255.0
 ip helper-address 1.1.1.1
 tunnel source Ethernet0/0
 tunnel mode ipv6
 tunnel destination 1::2

Server:
interface Ethernet0/0
 ip address 1.1.1.1 255.255.255.0
ip dhcp pool MAP
   network 2.2.2.0 255.255.255.0

server#show ip dhcp binding 
Bindings from all pools not associated with VRF:
IP address          Client-ID/	 	    Lease expiration        Type
		    Hardware address/
		    User name
2.2.2.1             0063.6973.636f.2d61.    Jun 13 2013 08:49 PM    Automatic

ce#show dhcp lease
Temp IP addr: 2.2.2.1  for peer on Interface: Tunnel0
Temp  sub net mask: 255.255.255.0
   DHCP Lease server: 1.1.1.1, state: 5 Bound
   DHCP transaction id: 45
   Lease: 86400 secs,  Renewal: 43200 secs,  Rebind: 75600 secs
   Next timer fires after: 11:54:32
   Retry count: 0   Client-ID: cisco-aabb.cc00.6500-Tu0
   Client-ID hex dump: 636973636F2D616162622E636330302E
                       363530302D547530
   Hostname: ce
ce#

this is an unchanged 15.1 release. just works.

there is MAP support on OpenWRT, but I haven't built the VM images to test that with yet.

[...]

> The problem is not already solved: the solution you are proposing requires changes on DHCP servers, DHCP clients, DHCP relay agents and probably stack changes as well to support the tunnel function…

it works with existing implementations for full IPv4 address over tunnels.
my draft and I can't see you have refuted that, suggests that it is quite simple to make the adjustments to also support the 
address sharing case.

it is easy to think that a completely new solution that only exists on the whiteboard will solve all problems better, old as well as new.
the pragmatic approach of small incremental change to existing stuff appears to me to be the safer choice.

> You and I went over this in painful detail in a long private email exchange at the end of the IETF meeting in Atlanta.   So I'm sorry if it seems to you that I am being unkind in my use of language…

I don't appreciate you trying to stifle the debate without letting others air their views.
this is the time for the DHC working group to thoroughly consider what the best approach to IPv4 over IPv6 softwires provisioning should be. it is a lot less time-wasting to do due diligence now. given that the DHC working group has decided to go down this path in the first place.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2013 21:21:37 +0000

> there is MAP support on OpenWRT, but I haven't built the VM images to test that with yet.

OK, so Public 4over6 with DHCP over the tunnel works on IOS.

> my draft and I can't see you have refuted that, suggests that it is quite simple to make the adjustments to also support the 

Yes, it is quite simple to make the changes.   All of the solutions we've talked about are quite simple.

> it is easy to think that a completely new solution that only exists on the whiteboard will solve all problems better, old as well as new.

There are several working implementations of DHCPv4 over IPv6.   I don't know if anybody's done DHCPv4 over DHCPv6 yet.   There is no existing implementation of what you are proposing.   So "only exists on the whiteboard" applies to what you are proposing.

> the pragmatic approach of small incremental change to existing stuff appears to me to be the safer choice.

It's always a great rhetorical idea to call the idea you favor "pragmatic" and requiring only "small incremental change," but that doesn't make it so.   In fact, the amount of change in your proposal is marginally more than required for DHCPv4-over-DHCPv6.   But this simply isn't a valid differentiating argument.   What you are proposing is neither pragmatic nor incremental in any sense that doesn't equally apply to all the other solutions.

> I don't appreciate you trying to stifle the debate without letting others air their views.

I can't stop you from airing your view, and I'm not proposing that anyone else not air theirs.   What I am saying is that the working group already considered your proposal, and three other competing proposals, and we'd already decided to go with DHCPv4-over-DHCPv6.   That is to say, the debate had already happened.   And now you want to reopen it.

> this is the time for the DHC working group to thoroughly consider what the best approach to IPv4 over IPv6 softwires provisioning should be. it is a lot less time-wasting to do due diligence now. g…

As an IETF participant, you are free to try to spend the working group's time continuing this debate.   The working group is free to continue debating this point until IPv6 deployment reaches 100%.   As a working group participant (that is, not an AD), I am advocating that the working group not do this.   What the working group actually decides to do is not up to me or to you.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2013 23:33:35 +0200

Ted,

> I can't stop you from airing your view, and I'm not proposing that anyone else not air theirs.   What I am saying is that the working group already considered your proposal, and three other competi…

sorry, then I must have missed that debate.

from the Orlando minutes I see I'm just following up on what I said then, which was:
          Ole: I think is a grand idea for now, but I reserve my right to change my
          mind tomorrow. Would it be easier to deploy if you colocate DHCPv4 and
          DHCPv6 servers?

anyway, I don't think continuing this tangential discussion between the two of us is good use of WG time.
if anyone else has comments or interest I would welcome that.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2013 21:44:54 +0000

>          mind tomorrow. Would it be easier to deploy if you colocate DHCPv4 and

:)

> if anyone else has comments or interest I would welcome that.

Ditto.

---

From: <[email-masked]>
Date: Thu, 13 Jun 2013 10:22:48 +0200

Hi Ole,

Thinking a little further on this, there's a bigger problem here. The DHCP
relay in the BR can catch the broadcast DHCP messages for address
allocations and create MAPping rules accordingly. However, the DHCP
release mechanism is unicast based, so how does remove the MAPping rules
once the DHCPv4 lease is no longer valid? Also, what about addresses that
don't get cleanly released and expire in the DHCPv4 server?

To fix this, either the DHCPv4 server has to be co-located in the BR, or
there's going to need to be a lot of DPI on DHCP unicast messages passing
through the BR, with corresponding lifetimes attached to the MAP rules.

Cheers,
Ian

>is no routing for in the network. configuration error. don't do it. ;-)

[ian] This one's a bit different to normal DHCPv4 relaying though. If the
routing is not correct in the network, the client will never get an
address and so DHCP will fail. In this case, if DHCP config is successful
then further DHCP communications will fail (without a mechanism for
creating dynamic MAPing rules).

>so that source port has to be allocated from the port range. while the
>well-known server port can stay unchanged
>and fixed at 67.

[ian] My mistake.

>I'm not either. I'm probably mostly advocating that only DHCPv6 should be
>used, and all services that otherwise would
>need IPv4 configuration information should run on IPv6. but then I'm
>known to be disconnected from reality too. ;-)
>
>cheers,
>Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Jun 2013 11:29:40 +0200

Ian,

> through the BR, with corresponding lifetimes attached to the MAP rules.

the DHCPv4 relay _could_ force all DHCP traffic to go through itself, by rewriting the server id.
that's apparently quite common, see RFC5107.

you do bring up a good point though; a stateful relay is really at odds with the MAP architecture of stateless BRs
where CEs use anycast to get to them.
any time you want redundancy you'd have a problem.

(to others following the discussion, we're now discussing the case of LW46 with complete indepdence
between IPv6 and IPv4 address, and where there is also no dependency between IPv6 provisioning
and IPv4 provisioning. none of this matter of course, if you just use DHCPv4 to get other configuration
information)

an out of band mechanism to populate per subscriber LW46/MAP state, would allow for stateless DHCP relays.

btw: force renew, that's not something generally used is it? cause supporting that I think would require the server to
include the client's UDP port in the binding, while otherwise it would not be required.

cheers,
Ole

---

From: Branimir Rajtar <[email-masked]>
Date: Wed, 12 Jun 2013 13:33:42 +0000

Hi,

BR,
Branimir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, June 12, 2013 1:31 PM
To: [email-masked] WG
Subject: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt

cheers,
Ole

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jun 2013 14:52:15 +0000

> If the BR works in DHCP relay mode, at the initial communication it will have to check if the source UDP port is 68 (given the source address is 0.0.0.0) and perform the relaying function. This is…

I don't think this is an issue—as long as the BR is willing to received packets sent to 255.255.255.255 over the tunnel, they will be delivered to the relay agent process on the BR by the IP stack without requiring any DPI.   That's something that would need to be documented and implemented, but as Ole has said, it already works on IOS, presumably without DPI.

---

From: <[email-masked]>
Date: Thu, 13 Jun 2013 17:49:50 +0200

Hi Ole,

I'm just doing an update to draft-ietf-dhc-v4configuration. Could you have
a look through the DHCPv4oSW relevant sections and see if you think that
any changes need to be made based on your draft / this discussion?

Cheers,
Ian

On 13/06/2013 11:29, "Ole Troan" <[email-masked]> wrote:

>you do bring up a good point though; a stateful relay is really at odds
>with the MAP architecture of stateless BRs

[ian] I think that the problem here is because successful softwire
provisioning in the BR is fundamental to how this works, then it's not
enough to say that an out of band mechanism will take care of this. It
needs to be covered

It does also mean that DHCPv4 over softwire is linked to having a
softwire. If another (non-softwire) reason for needing to provision IPv4
over and IPv6 native network appears in the future, then it's going to
need a softwire deployment.

>
>btw: force renew, that's not something generally used is it? cause
>supporting that I think would require the server to

[ian] I don¹t have any plans for using force renew. You can generally get
enough control with lease lengths.

---

From: Branimir Rajtar <[email-masked]>
Date: Fri, 14 Jun 2013 07:43:37 +0000

Hi,

I'm not sure whether or not I agree on this one. The BR should only perform "dumb" encapsulation and decapsulation of IP headers, and match them to the mapping table. If no match is found, the BR would then have to strip the IPv6 header and check whether or not the destination IP address is 255.255.255.255. and afterwards check the source UDP port.  IMHO, this would mess up the hardware optimization if you're doing encap-decap only.

However, I propose not to waste more time on this topic since it's not really significant to the overall discussion. Otherwise, I think we could waste days on this :)

Branimir

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, June 13, 2013 4:52 PM
To: Branimir Rajtar
Cc: Ole Troan; [email-masked] WG
Subject: Re: [dhcwg] New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt

> If the BR works in DHCP relay mode, at the initial communication it will have to check if the source UDP port is 68 (given the source address is 0.0.0.0) and perform the relaying function. This is…

I don't think this is an issue-as long as the BR is willing to received packets sent to 255.255.255.255 over the tunnel, they will be delivered to the relay agent process on the BR by the IP stack without requiring any DPI.   That's something that would need to be documented and implemented, but as Ole has said, it already works on IOS, presumably without DPI.

</FONT></P></HTML>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2013 10:30:31 +0000

> I'm not sure whether or not I agree on this one. The BR should only perform "dumb" encapsulation and decapsulation of IP headers, and match them to the mapping table. If no match is found, the BR w…

Oh, interesting.   I see your point.   Maybe the BR doesn't have an IPv4 address.   Thanks for being persistent in getting that point across—I wasn't even thinking in that direction.

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Jun 2013 12:38:58 +0200

Ted,

> Oh, interesting.   I see your point.   Maybe the BR doesn't have an IPv4 address.   Thanks for being persistent in getting that point across—I wasn't even thinking in that direction.

the BR is the device connecting the MAP domain to the IPv4 Internet. it has an IPv4 address.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2013 11:36:29 +0000

> the BR is the device connecting the MAP domain to the IPv4 Internet. it has an IPv4 address.

Is this a given?   Of course it will relay packets addressed to client IPv4 addresses to those clients, but does it have to have its _own_ IPv4 address?   Does it have to have an IPv4 stack?   Serious questions—I am by no means an expert on this, but I don't see why this would necessarily be the case.

I guess if you mean that the BR is a router through which all AFTR traffic is routed, and is not itself necessarily an AFTR, then you'd be right, but in that case the BR doesn't have access to the IPv6 address of the client, and doesn't even know which client a particular packet came from.

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Jun 2013 14:37:14 +0200

Ted,

> Is this a given?   Of course it will relay packets addressed to client IPv4 addresses to those clients, but does it have to have its _own_ IPv4 address?   Does it have to have an IPv4 stack?   Seri…

yes, that is a given. please read http://tools.ietf.org/html/draft-ietf-softwire-map-07

> I guess if you mean that the BR is a router through which all AFTR traffic is routed, and is not itself necessarily an AFTR, then you'd be right, but in that case the BR doesn't have access to the…

MAP Border Relay (BR):  A MAP enabled router managed by the service
                           provider at the edge of a MAP domain.  A
                           Border Relay router has at least an
                           IPv6-enabled interface and an IPv4 interface
                           connected to the native IPv4 network.  A MAP
                           BR may also be referred to simply as a "BR"
                           within the context of MAP.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2013 12:46:52 +0000

> yes, that is a given. please read http://tools.ietf.org/html/draft-ietf-softwire-map-07

How does that work with load balancing?   Does the map solution also cover the lw4over6 application in the unified CPE?

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Jun 2013 14:55:48 +0200

Ted,

> How does that work with load balancing?   Does the map solution also cover the lw4over6 application in the unified CPE?

yes, to last question.
for the first one:
in the CE -> BR direction. the BRs use an IPv6 anycast address (the same address for all BRs) as their tunnel endpoint. i.e the routing system between the CE and BR determines which BR to send to. (and that's the reason a stateless DHCP relay would definitely be the safest choice).
in the inbound BR direction (from the Internet), multiple BRs advertise a route for the same IPv4 prefix.

given equal routing costs you'll achieve ECMP.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Jun 2013 11:08:32 +0200

Ian,

> any changes need to be made based on your draft / this discussion?

let me give it a try. (with my limited knowledge of DHCPv4).

from the draft:

3.3.  DHCPv4oSW Based Provisioning

3.3.1.  Pros

   1.  Once implemented, all existing DHCPv4 options will be be
       available with no further ongoing development work necessary.

   2.  Uses the existing DHCPv4 and DHCPv6 architectures in order to
       provide IPv4 configuration in an IPv6 only environment.

   3.  DHCPv4 and DHCPv6 based provisioning can be separated from each
       other if required, allowing flexibility in network design.

* correct, but there might be an issue where the IPv4 address is configured both in
DHCPv4 and with the DHCPv6 MAP option.

3.3.2.  Cons

   1.  More complex, in that there are more new functional elements
       within the architecture than are necessary in DHCPv6 based
       provisioning.

* my position is that it is less new function elements. in that it just reuses
DHCPv4 as is. then we can argue over how big the tweaks actually turn out to be of course.
clearly it is more complex than just running DHCPv6 and not doing anything additional with DHCPv4,
but that's not what this draft is about right.

   2.  IPv4 over IPv6 softwire approaches which distribute NAT to the
       CPE and allow for IP address sharing (MAP-E & LW4o6) forbid the
       use of reserved TCP/UDP ports (e.g.  0-1024).  Every DHCPv4
       client sharing the same address needs to have a UDP listener
       running on UDP port 68.  To resolve this would require
       significant rework to either the softwire mechanisms and/or the
       DHCPv4 client implementation.

it is as simple as making the DHCPv4 client, relay and server port aware.
e.g. the ISC client supports setting port with a command line option already.

   3.  From the current specification, DHCPINFORM is not suitable for
       use over a softwire.  Additional work, such as the development of
       'shims' would be necessary

I was suggesting to support full blown DHCPv4, including DHCPINFORM of course.
isn't this point applicable to _any_ use of DHCPINFORM, if how it is supposed to
work isn't clear?

   4.  The current DHCPINFORM specification has a number of unclear
       points, such as those described in
       [I-D.ietf-dhc-dhcpinform-clarify].  Substantial work would be
       required to resolve this.

again is this specific to DHCPv4 over softwire, or does it apply to
the other DHCPv4 encaps as well?

   5.  Links the deployment of IPv4 configuration over IPv6 to a
       softwire implementation (e.g.  requiring a softwire concentrator
       to act as a DHCPv4 relay).  Whilst softwires are the only
       application for this functionality at the moment, this may not
       always be the case.

yes, I view that as a good thing. that the provisioning path follow the forwarding path.
and it is equivalent to how DHCPv4 is configured today. the PE is a DHCPv4 relay.

   6.  A new mechanism must be defined in order to provide the DHCPv4
       client with the IPv4 address of the DHCPv4 server so that unicast
       DHCPINFORM messages can be sent.

the biggest change to this draft, is that all DHCPv4 messages are supported.

   7.  As only DHCPINFORM/DHCPACK DHCPv4 message types are supported,
       dynamic IPv4 address leasing (using DHCPDISCOVER messages) can
       not be used.

again, this point should be removed. all messages can be supported.

   8.  The approach is unproven as no existing implementations exist.

partly true. given that we don't have the MAP DHCPv6 option yet.
as I said on the mailing list I did try DHCPv4 over a public 4over6 tunnel, and that
worked without changes. that's not fully applicable to a shared IPv4 tunnel obviously.

regardless of solution here, some new work is required, so point 8 probably applies to all
mechanisms in your analysis.

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Wed, 19 Jun 2013 09:14:25 +0800

Hi Ole,

>> How does that work with load balancing?   Does the map solution also cover the lw4over6 application in the unified CPE?

[Qi] Just to be clear, I do NOT intend to initiate the debates between lw4over6 and MAP, which happened in the Softwire WG. Just tell the WG what is lw4over6 from my understanding.
 IMO, lw4over6 is designed to keep IPv4 and IPv6 addressing independent. So it doesn't relay on IPv6 prefix delegation. Additionally, it supports on-demand IPv4-over-IPv6 service, while MAP advocates a static mapping (determined by MAP rules). I think that's why lw4over6 intends to use DHCPv4-over-IPv6 (currently it SHOULD use DHCPv4-over-DHCPv6), PCP, etc., which can maintain IPv4 leases dynamically.