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

From: Teemu Savolainen <[email-masked]>
Date: Mon, 16 Sep 2013 09:12:35 +0300

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

-----Original Message-----
From: "Tassos Chatzithomaoglou" <[email-masked]>
Sent: ‎15.‎9.‎2013 23:20
To: "[email-masked]" <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

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

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Mon, 16 Sep 2013 09:59:27 +0300

Teemu, MTU is already mentioned there.
I mentioned DNS, becasue i consider Prefix and DNS the duo responsible for basic internet connectivity, while MTU is something extra for even better connectivity.

If not explicitly defined, maybe the following statement needs to leave some space for other data that are passed to the LAN link through the RAs.

>
>    The LAN link originated RA message carries a copy of the following
>    3GPP radio link received RA message option fields:
>
>    o  MTU (if not provided by the 3GPP network, the UE will provide its
>       3GPP link MTU size)
>    o  Prefix Information

--
Tassos

Teemu Savolainen wrote on 16/9/2013 09:12:
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> From: Tassos Chatzithomaoglou <mailto:[email-masked]>
> Sent: ‎15.‎9.‎2013 23:20
> To: [email-masked] <mailto:[email-masked]>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 18 Sep 2013 14:59:08 -0700 (PDT)

+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 <[email-masked]>
>To: Tassos Chatzithomaoglou <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, 16 September 2013 4:12 PM
>________________________________
> From: Tassos Chatzithomaoglou
>Sent: ‎15.‎9.‎2013 23:20
>To: [email-masked]

---

From: <[email-masked]>
Date: Thu, 19 Sep 2013 20:40:57 +0200

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).

Holger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Mark ZZZ Smith
Gesendet: Mittwoch, 18. September 2013 23:59
An: Teemu Savolainen; Tassos Chatzithomaoglou; [email-masked]
Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC

+1

>> 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.
>>

---

From: "cb.list6" <[email-masked]>
Date: Thu, 19 Sep 2013 12:17:57 -0700

> 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…

I agree that is required for a functioning product, but this is not a
product specification it is a connectivity sharing method only with a
very narrow scope and hopefully narrow window of use if and when
DHCP-PD comes to mobile.

If you would like to specify that behavior, it would be best to
reference this I-D as the connectivity model for WAN and RFC 6204 for
a product LAN or just reference that the product MUST support this I-D
as well as the relevant DHCPv6 and/or RDNSS

CB

>>Sent: 15.9.2013 23:20

---

From: Teemu Savolainen <[email-masked]>
Date: Thu, 19 Sep 2013 23:40:17 +0300

The DNS handling might suite for draft-ietf-v6ops-mobile-device-profile
Section 4, but in my opinion not to this document as it is not within the
narrow scope.

Secondly, I don't agree DHCP server support is required, as the CE can
include the DNS addresses in RAs as specified in RFC6106.

Best regards,

Teemu
On Sep 19, 2013 9:41 PM, <[email-masked]> wrote:

> 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).
>
> Holger
>
> 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.
>
> >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
> >
> >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
> >

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 19 Sep 2013 13:51:32 -0700 (PDT)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, 20 September 2013 4:40 AM
> 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 
> 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.

> 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.
> 
>> To: Tassos Chatzithomaoglou <[email-masked]>; 
> "[email-masked]" 
>> <[email-masked]>
>> 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.
>> 
> 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
>> 
> proxy, or original through-RA/DHCPv6 DNS servers) should also pass on the LAN 
> link?
>> 
>> --
>> Tassos
>>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 19 Sep 2013 13:54:53 -0700 (PDT)

>To: [email-masked] 
>Cc: [email-masked] 
>Sent: Friday, 20 September 2013 6:40 AM
>The DNS handling might suite for draft-ietf-v6ops-mobile-device-profile Section 4, but in my opinion not to this document as it is not within the narrow scope.

Agree it is out of scope for this draft.

>Secondly, I don't agree DHCP server support is required, as the CE can include the DNS addresses in RAs as specified in RFC6106.
>

How could a CE convey NTP server settings to hosts using RAs? Accurate host time is pretty useful, if not essential.

---

From: Teemu Savolainen <[email-masked]>
Date: Fri, 20 Sep 2013 00:26:59 +0300

> >
>
> How could a CE convey NTP server settings to hosts using RAs? Accurate
host time is pretty useful, if not essential.

It cannot, but then again it probably would not help to have DHCP server
implementation either, as, AFAIK, cellular networks commonly today do not
provide DHCP service to terminals (to these "CEs" that would use 64share
instead of DHCPv6 PD).... 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?

... And this is why it is best to focus 64share to just prefix sharing;-)

Best regards,

Teemu

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 22 Sep 2013 20:36:54 +0200 (CEST)

> include the DNS addresses in RAs as specified in RFC6106.

There are very few products out there that supports this way of conveying 
DNS resolver information.

I am not opposed to say that providing basic 64share might skip supplying 
DNS resolver over IPv6, but then I agree with a few mail back where it was 
said we should have another document recommending how to get DNS resolver 
working for IPv6 only clients.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 22 Sep 2013 22:54:09 +0300

On Sep 22, 2013, at 9:36 PM, Mikael Abrahamsson <[email-masked]> wrote:

> There are very few products out there that supports this way of conveying DNS resolver information.
> 
> I am not opposed to say that providing basic 64share might skip supplying DNS resolver over IPv6, but then I agree with a few mail back where it was said we should have another document recommending how to get DNS resolver working for IPv6 only clients.

Why wouldn't we add this (rather obvious) requirement to draft-ietf-v6ops-mobile-device-profile? That would basically be just a clarification to Req#10.

- Jouni

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Sep 2013 04:55:13 +0200 (CEST)

> Why wouldn't we add this (rather obvious) requirement to draft-ietf-v6ops-mobile-device-profile? That would basically be just a clarification to Req#10.

Absolutely fine, draft-ietf-v6ops-mobile-device-profile could be this 
"other document".

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Sep 2013 16:03:00 +0200

Le 19/09/2013 22:54, Mark ZZZ Smith a écrit :
>
>> ________________________________ From: Teemu Savolainen
>> <[email-masked]> To: [email-masked] Cc:
>> [email-masked] Sent: Friday, 20 September 2013 6:40 AM Subject: Re:
>> [v6ops] draft-ietf-v6ops-64share WGLC
>>
>>
>>
>> The DNS handling might suite for
>> draft-ietf-v6ops-mobile-device-profile Section 4, but in my opinion
>> not to this document as it is not within the narrow scope.
>
>> Secondly, I don't agree DHCP server support is required, as the CE
>> can include the DNS addresses in RAs as specified in RFC6106.
>>
>
> How could a CE convey NTP server settings to hosts using RAs?
> Accurate host time is pretty useful, if not essential.

In addition to NTP time, DHCP would be needed to deliver a prefix as 
well (in the sense of prefix delegation), because RA couldnt.

(yes accurate time is often essential in safety and mission-critical 
applications).

Still, the 64share method is useful and it works.

Alex

>
>
>
>>
>> Best regards, Teemu On Sep 19, 2013 9:41 PM,
>> <[email-masked]> wrote:
>>
>> 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).
>>>
>>> Holger
>>>
>>> -----Ursprüngliche Nachricht----- Von: [email-masked]
>>> [mailto:[email-masked]] Im Auftrag von Mark ZZZ Smith
>>> Gesendet: Mittwoch, 18. September 2013 23:59 An: Teemu
>>> Savolainen; Tassos Chatzithomaoglou; [email-masked] 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.
>>>
>>>> From: Teemu Savolainen <[email-masked]> To: Tassos
>>>> Chatzithomaoglou <[email-masked]>; "[email-masked]"
>>>> <[email-masked]> Sent: Monday, 16 September 2013 4:12 PM
>>>> 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: [email-masked] 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
>>>>
>>>>> 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,
>>>>> 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 [email-masked]
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Sep 2013 16:09:18 +0200

Le 19/09/2013 23:26, Teemu Savolainen a écrit :
> implementation either, as, AFAIK, cellular networks commonly today do
> not provide DHCP service to terminals (to these "CEs" that would use
> 64share instead of DHCPv6 PD)....

In addition to considering whether or not the cellular network delivers 
DHCP, one should consider whether or not the local USB dongle delivers 
DHCP to the Host.

This or someone other unknown entity in the middle, between the network 
and the host, delivers DHCP and make that link look like ARP-capable 
link.  The QMI drivers and clients in linux see new evolutions in that 
sense.

But that is more like future work; 64share has place here where QMI is 
not yet widely deployed.

> 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?

> ... And this is why it is best to focus 64share to just prefix sharing;-)

In a sense I agree to let 64share just do the prefix sharing.

But obviously the client on the LAN side needs a way to get a DNS server 
address otherwise its connectivity is only partial.

Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 23 Sep 2013 13:07:16 -0700 (PDT)

> From: Alexandru Petrescu <[email-masked]>
>To: [email-masked] 
>Sent: Tuesday, 24 September 2013 12:09 AM
>>  > >Secondly, I don't agree DHCP server support is required, as the CE
>>  > >
>>  >
>>  > How could a CE convey NTP server settings to hosts using RAs?

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 23 Sep 2013 13:15:50 -0700 (PDT)

----- Original Message -----
> From: Mark ZZZ Smith <[email-masked]>
> To: Alexandru Petrescu <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Tuesday, 24 September 2013 6:07 AM

<snip>

> 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
> 

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.

---

From: <[email-masked]>
Date: Thu, 26 Sep 2013 10:01:05 +0200

Hi all,

fine with me as well. However, Req#10 is not the correct place since that's only about the DHCPv6 client mode of the mobile. Around Req#27 would be a better place, however, the link to RFC6204 and Req L-10 there more or less indicates what must be done without explicitly stating the detailed procedure.

Holger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Mikael Abrahamsson
Gesendet: Montag, 23. September 2013 04:55
An: Jouni Korhonen
Cc: [email-masked]
Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC

> Why wouldn't we add this (rather obvious) requirement to draft-ietf-v6ops-mobile-device-profile? That would basically be just a clarification to Req#10.

Absolutely fine, draft-ietf-v6ops-mobile-device-profile could be this "other document".