>> it is expected that path MTU discovery works in the IPv6 Internet (sic!)
> 
> The purpose of this specification is for avoiding PMTU at least the LAN side 
> hosts of 6rd CPE.
> Is this correct?

that's correct.

cheers,
Ole


>> Satoru-san,
>> 
>>>> if you are thinking of the text in RFC4861 I read that as an _example_ of 
>>>> a case where the MTU option could be used. do you see any problems with 
>>>> recommending to match the LAN-side MTU with the WAN-side MTU? assuming we 
>>>> cannot get to something like SEAL in time (RFC5320)
>>> 
>>> 
>>> No, I just surprised by this specification which matching the LAN side MTU 
>>> size with the WAN side MTU size.
>>> Is this generic way even CPE can response to host with "packet too big" 
>>> message?
>>> If it is generic, why  not in BR side?
>> 
>> it is expected that path MTU discovery works in the IPv6 Internet (sic!). 
>> there isn't much one can do with the native IPv6 side MTU on the BR in any 
>> case. of course the BR tunnel MTU has to be managed as described.
>> 
>> cheers,
>> Ole
>> 
>>>> Matsushima-san,
>>>> 
>>>>> I have a question about MTU option in router advertisement.
>>>>> The draft says:
>>>>> 
>>>>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined
>>>>>> automatically or configured directly, on the LAN side by setting the
>>>>>> MTU option in Router Advertisements [RFC4861] messages to the 6rd
>>>>>> Tunnel MTU."
>>>>> 
>>>>> My understanding of the role of MTU option in RA is that if hosts are in
>>>>> configuration in which different media type are bridged, advertising mtu 
>>>>> size
>>>>> all media supported.
>>>>> 
>>>>> Does CPE should advertise the 6rd Tunnel MTU even 6rd tunnel does not 
>>>>> bridged 
>>>>> to CPE LAN side?
>>>> 
>>>> if you are thinking of the text in RFC4861 I read that as an _example_ of 
>>>> a case where the MTU option could be used. do you see any problems with 
>>>> recommending to match the LAN-side MTU with the WAN-side MTU? assuming we 
>>>> cannot get to something like SEAL in time (RFC5320)
>>>> 
>>>> Best regards,
>>>> Ole
>>>> 
>>>> 
>>>>>> hi,
>>>>>> 
>>>>>> we've just posted an updated revision of the 6rd draft, which we
>>>>>> believe is ready for last call in the softwires and dhc working
>>>>>> groupsl.
>>>>>> 
>>>>>> apart from cleaning up text the main changes are in the DHCP option,
>>>>>> which now includes a list of BR IPv4 addresses. (I misread RFC3396 to
>>>>>> allow for multiple DHCP options as a way of doing this, unfortunately
>>>>>> not so with the format we had. thanks to the dhc wg expers for
>>>>>> correcting me.)
>>>>>> 
>>>>>> we have also taken out all deployment considerations which were in the
>>>>>> revision 03 draft. if anyone is interested in taking that work up, it
>>>>>> could be a separate draft in v6ops.
>>>>>> 
>>>>>> the complete diff-set is available here:
>>>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ipv6-6rd-04.txt
>>>>>> 
>>>>>> Best regards,
>>>>>> Ole
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------- Forwarded message ----------
>>>>>> From:  <[email protected]>
>>>>>> Date: Wed, Feb 3, 2010 at 4:45 PM
>>>>>> Subject: [Softwires] I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt
>>>>>> To: [email protected]
>>>>>> Cc: [email protected]
>>>>>> 
>>>>>> 
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>>>> directories.
>>>>>> This draft is a work item of the Softwires Working Group of the IETF.
>>>>>> 
>>>>>> 
>>>>>>  Title           : IPv6 via IPv4 Service Provider Networks "6rd"
>>>>>>  Author(s)       : M. Townsley, O. Troan
>>>>>>  Filename        : draft-ietf-softwire-ipv6-6rd-04.txt
>>>>>>  Pages           : 16
>>>>>>  Date            : 2010-02-03
>>>>>> 
>>>>>> This document specifies an automatic tunneling mechanism tailored to
>>>>>> advance deployment of IPv6 to end users via a Service Provider's IPv4
>>>>>> network infrastructure.  Key aspects include automatic IPv6 prefix
>>>>>> delegation to sites, stateless operation, simple provisioning, and
>>>>>> service which is equivalent to native IPv6 at the sites which are
>>>>>> served by the mechanism.
>>>>>> 
>>>>>> A URL for this Internet-Draft is:
>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-04.txt
>>>>>> 
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>> 
>>>>>> Below is the data which will enable a MIME compliant mail reader
>>>>>> implementation to automatically retrieve the ASCII version of the
>>>>>> Internet-Draft.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Softwires mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>> _______________________________________________
>>>>>> Softwires mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>> 
>>>> 
>>> 
>> 
> 

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to