Ole-san, > 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? Regards, --satoru On 2010/02/05, at 20:17, Ole Troan wrote: > 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
