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

[Alexandru Petrescu <[e-mail]>]

Le 19/09/2013 22:54, Mark ZZZ Smith a écrit :
>
>> ________________________________ From: Teemu Savolainen
>> <[e-mail]> To: [e-mail] Cc:
>> [e-mail] 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.
>
> 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.

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,
>> <[e-mail]> 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: [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
>>>
>> _______________________________________________ v6ops mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>