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

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

----- Original Message -----
> From: "[e-mail]" <[e-mail]>
> To: [e-mail]
> Cc: 
> Sent: Friday, 20 September 2013 4:40 AM
> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
> 
> Hello all,
> 
> I believe this needs to be looked at. DNS server addresses are sent from the 
> network to the mobile host ("CE" in this scenario) by outband 3GPP 
> signalling and need to be queried by the CE OS driver from the radio chip.
> 
> In order to convey the DNS information to the clients attached via the LAN, the 
> CE performing 64share needs to handle the DHCP solicits and answer on the 
> network's behalf because simply forwarding the DHCP solicits will not work 
> at all (the network won't answer them).
> 

off-topic for 64share, but perhaps briefly worth discussing as these devices are another example of the issues I identified in the draft.


That's pretty much one of the fundamental problems of embedding application layer configuration parameters in a layer 2 protocol. This was also the mistake made with IPv4 IPCP in PPP, and fixed in IPv6 by using DHCPv6 over PPP, than using IPV6CP for parameters "in" PPP.

While DNS is the most common application parameter, I don't think it is a good idea to assume it is the only useful parameter that could be conveyed to a host. Perhaps people don't think there is anything useful outside of DNS because that's basically all IPv4 PPP could convey (other than Microsoft Netbios Name Server settings). In other words, a past constraint has limited people's perception of what is or could be useful.

The DHCPv6 options I think of as examples of useful parameters that can't be conveyed to hosts in either the RFC6204 or it seems implementation models such as this are the geolocation DHCPv6 options. It might be useful for a client to be told by the network operator it's geolocation information, but that isn't possible with e.g., RFC6204, even though there are DHCPv6 options that can convey that information. The argument could be to add those options into the specs, but that is just leaving the constraint in place, and creating extra work in the future when other useful options may be defined.

My fundamental goal is to see the end of ISP settings configuration pages, for customers to cut-and-paste settings from. I think it is quite ridiculous that we've solved so many other problems, yet persist with customers (or their technical relatives) having to type in their email server address or sip server address etc. into their devices. It's quite un-user friendly, and a problem that should be easy to solve, considering the much harder ones that have been.

Regards,
Mark.



> Holger
> 
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Mark 
> ZZZ Smith
> Gesendet: Mittwoch, 18. September 2013 23:59
> An: Teemu Savolainen; Tassos Chatzithomaoglou; [e-mail]
> Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC
> 
> +1
> 
> This purpose here is to describe a work around to a limitation, not to specify 
> how RAs/DHCPv6 are supposed to be generally used and what options are present in 
> them. I don't think RA or DHCPv6 options that aren't essential or useful 
> to this *specific* scenario should be mentioned at all. DNS in RAs is not 
> special to or necessary to sharing a /64.
> 
> Generally related to DHCPv6 option passing across a CE device (of which this 
> would be one), I posted the following draft a while ago. I'd be interested 
> in comments.
> 
> "IPv6 CE Device DHCPv6 Option Transparency"
> 
> http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00
> 
> 
> 
> 
> 
>> ________________________________
>>  From: Teemu Savolainen <[e-mail]>
>> To: Tassos Chatzithomaoglou <[e-mail]>; 
> "[e-mail]" 
>> <[e-mail]>
>> Sent: Monday, 16 September 2013 4:12 PM
>> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>> 
>> 
>> 
>> IMHO it is better to keep this draft focused solely on address sharing, and 
> not to go to other configuration topic or other possible problems.
>> 
>> Btw most often, as of now, the "original" DNS server addresses are 
> received via link layer signaling (see 
> http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.txt section 2.10), and 
> thus, for example, may need to be added to "proxied" RA.
>> 
>> Best regards,
>> 
>> Teemu
>> 
>> ________________________________
>>  From: Tassos Chatzithomaoglou
>> Sent: ‎15.‎9.‎2013 23:20
>> To: [e-mail]
>> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>> 
>> Just a quick question...
>> 
>> I don't see any reference of DNS servers under 3.1, only MTU & 
> Prefix.
>> Shouldn't there be a bullet showing that DNS info (UE address as DNS 
> proxy, or original through-RA/DHCPv6 DNS servers) should also pass on the LAN 
> link?
>> 
>> --
>> Tassos
>> 
>> Fred Baker wrote on 15/9/2013 21:00:
>>>  This is to initiate a two week working group last call of 
>>>  http://tools.ietf.org/html/draft-ietf-v6ops-64share.  Please read it 
>>>  now. If you find nits (spelling errors, minor suggested wording 
>>>  changes, etc), comment to the authors; if you find greater issues, 
>>>  such as disagreeing with a statement or finding additional issues 
>>>  that need to be addressed, please post your comments to the list.
>>> 
>>>  We are looking specifically for comments on the importance of the 
>>>  document as well as its content. If you have read the document and 
>>>  believe it to be of operational utility, that is also an important 
>>>  comment to make.
>>>  _______________________________________________
>>>  v6ops mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>