Re: [v6ops] draft-ietf-v6ops-64share WGLC

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Mark ZZZ Smith <[e-mail]>
> To: Alexandru Petrescu <[e-mail]>; "[e-mail]" <[e-mail]>
> Cc: 
> Sent: Tuesday, 24 September 2013 6:07 AM
> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
> 
> 
> 
> 
> 

<snip>

>> 
>>>  If CE has no NTP settings, it cannot
>>>  share them either. CE often gets time from cellular network, though.. 
> So
>>>  maybe CE should implement NTP server and with DHCP share its own 
> address
>>>  as NTP address?
>> 
>> CE to run a DHCPv6 Server?
>> 
> 
> I think the CE should run a DHCPv6 relay, not a DHCPv6 server. Otherwise, the 
> parameters the upstream "network" and the downstream hosts can receive 
> are constrained by the DHCPv6 option support of the DHCPv6 client/server in the 
> CE device. This is what I've discussed, including how I think stateful 
> DHCPv6 addressing could be handled on the downstream interface, in
> 
> "IPv6 CE Device DHCPv6 Option Transparency"
> 
> http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00
> 
> 


I've realised in the last week or so that I need to generalise the draft, so that what it proposes applies to all IPv6 routers, including 3G smartphones/tablets etc., not just RFC6204 ones. I'll work on updating it over the next week or so. Here's the current abstract:


"[RFC6204] defines basic requirements for IPv6 Customer Edge Routers,
to suit residential or small office IPv6 deployments.  It describes a WAN interface DHCPv6 client and LAN interface DHCPv6 server implementation model.  This model constrains the set of DHCPv6 options that can be conveyed between the upstream service provider and the hosts downstream of the CE device, to those supported by both the CE device's DHCPv6 client and server.  To support further current and future DHCPv6 options, this memo instead proposes a DHCPv6 option "transparent" implementation model for CE devices, primarily using DHCPv6 message relaying."

Thanks,
Mark.