Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels

["Templin, Fred L" <[e-mail]>]

Hi Washam, 

> -----Original Message-----
> From: Washam Fan [mailto:[e-mail]] 
> Sent: Thursday, October 14, 2010 5:50 AM
> To: Templin, Fred L
> Cc: Rémi Després; Softwires; [e-mail]
> 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
[e-mail]

> 2010/10/13 Templin, Fred L <[e-mail]>:
> > Hi Washam,
> >
> >> -----Original Message-----
> >> From: Washam Fan [mailto:[e-mail]]
> >> Sent: Monday, October 11, 2010 10:48 PM
> >> To: Templin, Fred L
> >> Cc: Rémi Després; Softwires; [e-mail]
> >> 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
> > [e-mail]
> >
> >> Thanks,
> >> washam
> >>
> >> 2010/10/12 Templin, Fred L <[e-mail]>:
> >> > Hi Washam,
> >> >
> >> >> -----Original Message-----
> >> >> From: Washam Fan [mailto:[e-mail]]
> >> >> Sent: Monday, October 11, 2010 7:38 PM
> >> >> To: Templin, Fred L
> >> >> Cc: Rémi Després; Softwires; [e-mail]
> >> >> 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
> >> > [e-mail]
> >> >
> >> >> Thanks,
> >> >> washam
> >> >>
> >> >> 2010/10/12 Templin, Fred L <[e-mail]>:
> >> >> > Remi,
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: Rémi Després [mailto:[e-mail]]
> >> >> >> Sent: Monday, October 11, 2010 10:05 AM
> >> >> >> To: Templin, Fred L
> >> >> >> Cc: Washam Fan; Softwires; [e-mail]
> >> >> >> 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
> >> >> > [e-mail]
> >> >> >
> >> >> >> RD
> >> >> >
> >> >>
> >>
>