Subject: [Softwires] Fwd: New Version Notification for draft-fsc-softwire-dhcp4o6-saddr-opt-00.txt

From: Qi Sun <[email-masked]>
Date: Tue, 1 Jul 2014 19:28:39 +0800

Dear all, 

We have submitted a new draft about using DHCPv4 over DHCPv6 with some IPv4-over-IPv6 softwire mechanisms. This draft follows the essence of the ’Softwire DHCP Options’ document with a new container grouping related sub-options. 

Comments are more than welcome.

Best Regards,
Qi

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-fsc-softwire-dhcp4o6-saddr-opt-00.txt
> Date: July 1, 2014 at 7:24:28 PM GMT+8
> To: Yong Cui <[email-masked]>, Ian Farrer <[email-masked]>, "Qi Sun" <[email-masked]>, Qi Sun <[email-masked]>, "Ian Farrer" <[email-masked]>, "Yong Cui" <[email-masked]>
> 
> 
> A new version of I-D, draft-fsc-softwire-dhcp4o6-saddr-opt-00.txt
> has been successfully submitted by Qi Sun and posted to the
> IETF repository.
> 
> Name:		draft-fsc-softwire-dhcp4o6-saddr-opt
> Revision:	00
> Title:		DHCPv4 over DHCPv6 Source Address Option
> Document date:	2014-06-30
> Group:		Individual Submission
> Pages:		8
> URL:            http://www.ietf.org/internet-drafts/draft-fsc-softwire-dhcp4o6-saddr-opt-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-fsc-softwire-dhcp4o6-saddr-opt/
> Htmlized:       http://tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-00
> 
> 
> Abstract:
>   DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes a
>   mechanism for dynamically configuring IPv4 over an IPv6-only network.
>   For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire
>   mechanisms, the operator must obtain information about the IPv4
>   address and Port Set ID allocated to the DHCP 4o6 client, as well as
>   the /128 IPv6 prefix that the client will use as the source of IPv4-
>   in-IPv6 tunnel.  This memo defines a DHCPv6 container option and two
>   DHCPv6 sub-options, to communicate the source tunnel IPv6 address
>   between the DHCP 4o6 client and server.  It is designed to work in
>   conjunction with the IPv4 address allocation process.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 01 Jul 2014 22:46:17 -0400

Suppose a CE changes the IPv6 address it uses for tunnel endpoint 
subsequent to the initial establishment of the tunnel. What would the 
message flow be between the CE and the DHCP server(s) to update the latter?

Tom Taylor

> Comments are more than welcome.
...

---

From: Qi Sun <[email-masked]>
Date: Wed, 2 Jul 2014 12:32:17 +0800

Dear Tom,

Thanks for the comment. 

There is some text in the Sec 9 in draft-ietf-dhc-dhcpv4-over-dhcpv6-09, which may be related to this:

   If the IPv6 configuration that contained the 4o6
   Server Address option subsequently expires, or if the renewed IPv6
   configuration does not contain the 4o6 Server Address option, the
   client MUST stop using DHCPv4 over DHCPv6 to request or renew IPv4
   configuration.  However, the client continues to request 4o6 Server
   Address option in the messages sent to the DHCPv6 server as long as
   it desires to use DHCPv4 over DHCPv6.

So if a CE changes the binding IPv6 address in the context of normal DHCPv6 operation, it has a chance to update the information to the DHCP server. 

Best Regards,
Qi

On Jul 2, 2014, at 10:46 AM, Tom Taylor <[email-masked]> wrote:

> Suppose a CE changes the IPv6 address it uses for tunnel endpoint subsequent to the initial establishment of the tunnel. What would the message flow be between the CE and the DHCP server(s) to update the latter?
> 
> Tom Taylor
>

---

From: <[email-masked]>
Date: Wed, 2 Jul 2014 08:57:35 +0200

Hi Tom,

On top of Qi¹s reply, the lw4o6 base spec also has the following in
section 5.1:

In the event that the lwB4's encapsulation source address is changed
   for any reason (such as the DHCPv6 lease expiring), the lwB4's
   dynamic provisioning process must be re-initiated.

Cheers,
Ian

On 02/07/2014 04:46, "Tom Taylor" <[email-masked]> wrote:

>> We have submitted a new draft about using DHCPv4 over DHCPv6 with some
>>IPv4-over-IPv6 softwire mechanisms. This draft follows the essence of
>>the ¹Softwire DHCP Options¹ document with a new container grouping
>>related sub-options.
>>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: Tom Taylor <[email-masked]>
Date: Wed, 02 Jul 2014 09:19:46 -0400

That doesn't really deal with a change of address at the client. As an 
example, I'm thinking of a CE that changes its address regularly for 
privacy reasons. Of course, one answer you may give me is that 
autonomous address changes by the CE are out of scope or not allowed.

Tom

---

From: Tom Taylor <[email-masked]>
Date: Wed, 02 Jul 2014 09:21:39 -0400

OK, this addresses the question.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Jul 2014 09:30:57 -0400

On Jul 2, 2014, at 9:19 AM, Tom Taylor <[email-masked]> wrote:
> That doesn't really deal with a change of address at the client. As an example, I'm thinking of a CE that changes its address regularly for privacy reasons. Of course, one answer you may give me is that autonomous address changes by the CE are out of scope or not allowed.

A CE that changes its privacy address regularly can still have a stable address for connections where privacy isn't an issue.   That's the current architecture: that's why we have temporary addresses.   There's no use case for using a temporary address when tunneling IPv4 traffic through your ISP's gateway.