Hi Brian, > -----Original Message----- > From: v4tov6transition-boun...@ietf.org > [mailto:v4tov6transition-boun...@ietf.org] On Behalf Of Brian > E Carpenter > Sent: Thursday, October 14, 2010 3:10 PM > To: Templin, Fred L > Cc: Softwires; v4tov6transit...@ietf.org > Subject: Re: [v4tov6transition] IPv6 VPNs configured over > 1280 MTU tunnels > > Fred, > > > All of your assumptions are lowest-common-denominator. > > What else can an operator safely do but make such assumptions?
They can roll up their sleeves and probe the paths to the clients. Thanks - Fred fred.l.temp...@boeing.com > Regards > Brian > > On 2010-10-15 02:08, Templin, Fred L wrote: > > Hi Washam, > > > >> -----Original Message----- > >> From: Washam Fan [mailto:washam....@gmail.com] > >> Sent: Thursday, October 14, 2010 5:50 AM > >> To: Templin, Fred L > >> Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org > >> Subject: Re: [v4tov6transition] IPv6 VPNs configured over > >> 1280 MTU tunnels > >> > >> Hi Fred, > >> > >> Please see inline. I did have some different assumptions. And those > >> assumptions might be wrong. It might be better at this stage we let > >> the tunneled IPv6 MTU be 1280 and tunneling IPv4 MTU not less than > >> 1308. > > > > All of your assumptions are lowest-common-denominator. > > All end user networks are made to suffer because of the > > few that are poorly configured. GigE is a current day > > reality, and MTUs much larger than the lowest common > > denominator should be made available to the end user > > networks that paid good money for them when possible. > > > > Fred > > fred.l.temp...@boeing.com > > > >> 2010/10/13 Templin, Fred L <fred.l.temp...@boeing.com>: > >>> Hi Washam, > >>> > >>>> -----Original Message----- > >>>> From: Washam Fan [mailto:washam....@gmail.com] > >>>> Sent: Monday, October 11, 2010 10:48 PM > >>>> To: Templin, Fred L > >>>> Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org > >>>> Subject: Re: [v4tov6transition] IPv6 VPNs configured over > >>>> 1280 MTU tunnels > >>>> > >>>> Hi Fred, > >>>> > >>>> I might see your points. > >>> Good. > >>> > >>>> Let H represents Host, N represents NAT, S represents the 6a44 > >>>> servers. PMTU(H,S) stands for the PMTU between H and S. HOME_MTU > >>>> represents MTU within home LAN (i.e., unmanaged network), SP_MTU > >>>> represents MTU within SP network(i.e., managed network). > We assume > >>>> both SP_MTU and SP_MTU should exceed or equal to 1308. > >>> This is an incomplete characterization. PMTU is not > >>> necessarily symmetric, e.g., even just within the end > >>> user it could be different in the H->N direction than > >>> in the N->H direction. Also, there could be multiple N's > >>> in the path; each imparting their own MTU uncertainties. > >> I assume H->N->S PMTU can be probed, Ns in between should > be capable > >> of translating ICMPv4 messages appropriately. As you said, > S->N->H can > >> not be probed as Ss are stateless. > >> > >>>> if HOME_MTU>=SP_MTU, PMTU(H,S)=SP_MTU, the H could > >> configure SP_MTU-28 > >>>> as the IPv6 virtual interface MTU. > >>> A couple of things here. First, you seem to be assuming a > >>> static S instead of a redundantly replicated S with anycast, > >>> where there may be many distinct paths with varing SP_MTUs to > >>> reach the multiple S's. > >> I assume all Ss shared the same MTUs since they are > located in managed > >> networks. Or the MTU on their interfaces attaching SP > networks can be > >> configured with the least IPv4 MTU value. > >> > >>> Second, how does H discover SP_MTU; > >>> by engaging in an initial probing by sending large packets > >>> and getting a PTB message back? > >> I assume H can discover PMTU traversing Ns in between. > >> > >>> Again, this won't give a > >>> deterministic SP_MTU value if S is replicated across paths > >>> with varying PMTUs. > >> I assume all Ss configured with the same MTUs on their interfaces > >> attaching to SP networks. > >> > >>>> H->S direction: if S received or trigger any ICMPv6 PTB > >> messages, it > >>>> can forward ICMPv6-in-UDP-in-IPv4 to H. > >>> You keep saying this, and I keep saying that you are right > >>> but that this has never been a matter for concern. PMTUD > >>> *beyond* the tunnel is not in question; it is only PMTUD > >>> *within* the tunnel that bears further discussion. > >>> > >>>> S->H direction: S would reject any IPv6 packets > exceeding SP_MTU-28 > >>>> with ICMPv6 PTB. > >>>> I don't see problems here. > >>> Huh? Is S supposed to cache the SP_MTU to each and every > >>> potential host H? I assume the goal is for a completely > >>> stateless S - right? > >> I assume MTU is statically configured on Ss' interfaces > attaching the > >> SP networks. > >> > >>>> If HOME_MTU<SP_MTU,PMTU(H,S)=HOME_MTU, the H could configure > >>>> HOME_MTU-28 as IPv6 virtual interface MTU. > >>> So again, H could discover this only by sending probes? > >>> And again, any probing would be non-deterministic if S > >>> is an anycast (and not unicast) address. > >> See above. > >> > >> Thanks, > >> washam > >> > >>>> H->S direction: if S received or trigger any ICMPv6 PTB > >> messages, it > >>>> can forward ICMPv6-in-UDP-in-IPv4 to H. > >>> Yes, we have confirmed this several times now; not > >>> a point in question. > >>> > >>>> I don't expect the size of the encapsulated packet is too much. > >>> Encapsulated PTB could be as big as 1280 + 20 + 8. > >>> > >>>> S->H direction: if S forward some IPv6 packets whose size > >> is between > >>>> HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or > >> filtering > >>>> them. For the former, S might don't have enough info to > infer which > >>>> IPv6 original packet it is related, > >>> Right. > >>> > >>>> for the latter, black hole might occur. I see problems here. > >>> Right. > >>> > >>> Fred > >>> fred.l.temp...@boeing.com > >>> > >>>> Thanks, > >>>> washam > >>>> > >>>> 2010/10/12 Templin, Fred L <fred.l.temp...@boeing.com>: > >>>>> Hi Washam, > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Washam Fan [mailto:washam....@gmail.com] > >>>>>> Sent: Monday, October 11, 2010 7:38 PM > >>>>>> To: Templin, Fred L > >>>>>> Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org > >>>>>> Subject: Re: [v4tov6transition] IPv6 VPNs configured over > >>>>>> 1280 MTU tunnels > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> If 6a44 deployed in a managed ISP network, the 6a44 > >> client could be > >>>>>> configured with IPv4_MTU-28 for its IPv6 MTU. > >>>>> My understanding is that the 6a44 server is in the managed > >>>>> ISP network, and the 6a44 client is in the UNmanaged end > >>>>> user network. > >>>>> > >>>>>> For inbound direction, > >>>>>> 6a44 server would reject any IPv6 packets whose size exceeds > >>>>>> IPv4_MTU-28 with a ICMPv6 PTB message, so no ICMPv6-ICMPv4 > >>>> translation > >>>>>> needed. > >>>>> Huh? How does the server have any idea what MTU the client > >>>>> set on its tunnel interface? The client is behind a NAT in > >>>>> an unmanaged end user network. Are you expecting the server > >>>>> to probe the path MTU to the client and maintain state? (An > >>>>> IRON server might be in position to do something like that, > >>>>> but I was assuming the 6a44 server would be stateless, right?) > >>>>> > >>>>>> For outbound direction, 6a44 server would encapsulate any > >>>>>> ICMPv6 PTB messages it received in UDP in IPv4, and > >> then forward to > >>>>>> the 6a44 client, so no NAT filtering worried. > >>>>> Correct, but no one has suggested an MTU problem for what > >>>>> happens to IPv6 packets *beyond* the tunnel; we are only > >>>>> discussing the case of MTU issues *within* the tunnel. > >>>>> > >>>>> Fred > >>>>> fred.l.temp...@boeing.com > >>>>> > >>>>>> Thanks, > >>>>>> washam > >>>>>> > >>>>>> 2010/10/12 Templin, Fred L <fred.l.temp...@boeing.com>: > >>>>>>> Remi, > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Rémi Després [mailto:remi.desp...@free.fr] > >>>>>>>> Sent: Monday, October 11, 2010 10:05 AM > >>>>>>>> To: Templin, Fred L > >>>>>>>> Cc: Washam Fan; Softwires; v4tov6transit...@ietf.org > >>>>>>>> Subject: Re: [v4tov6transition] IPv6 VPNs configured over > >>>>>>>> 1280 MTU tunnels > >>>>>>>> > >>>>>>>> > >>>>>>>> Le 11 oct. 2010 à 18:42, Templin, Fred L a écrit : > >>>>>>>> > >>>>>>>>>> ... > >>>>>>>>>> Actually, the 6a44 specification should, instead of 1280, > >>>>>>>>>> require IPv4 MTU - 28 octets, both for hairpinning and > >>>>>>>>>> traversal cases. > >>>>>>>>> How can you be sure that IPv4 PMTUD will work in > >>>>>>>>> the traversal case? > >>>>>>>> In the to-host direction, because the ISP network is all what > >>>>>>>> is left to traverse before reaching the CPE. > >>>>>>> In what you call the to-host direction, any ICMPv4 > >>>>>>> returned from the ISP network might not have enough > >>>>>>> information for stateless translation to ICMPv6. > >>>>>>> > >>>>>>>> In the from host direction, one can't be sure, but > >>>> doesnt' need to. > >>>>>>>> If a smaller PMTU is encountered further downstream, a PTB > >>>>>>>> ICMPv6 error message will be returned from there. > >>>>>>> In the from-host direction, any ICMPv4 returned from > >>>>>>> the ISP network might not be delivered to the tunnel > >>>>>>> endpoint due to NAT filtering, and might not have > >>>>>>> enough information for stateless translation to ICMPv6. > >>>>>>> > >>>>>>> Fred > >>>>>>> fred.l.temp...@boeing.com > >>>>>>> > >>>>>>>> RD > > _______________________________________________ > > v4tov6transition mailing list > > v4tov6transit...@ietf.org > > https://www.ietf.org/mailman/listinfo/v4tov6transition > > > > _______________________________________________ > v4tov6transition mailing list > v4tov6transit...@ietf.org > https://www.ietf.org/mailman/listinfo/v4tov6transition > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires