Hi Washam, > -----Original Message----- > From: Washam Fan [mailto:[email protected]] > Sent: Thursday, October 14, 2010 5:50 AM > To: Templin, Fred L > Cc: Rémi Després; Softwires; [email protected] > 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 [email protected] > 2010/10/13 Templin, Fred L <[email protected]>: > > Hi Washam, > > > >> -----Original Message----- > >> From: Washam Fan [mailto:[email protected]] > >> Sent: Monday, October 11, 2010 10:48 PM > >> To: Templin, Fred L > >> Cc: Rémi Després; Softwires; [email protected] > >> 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 > > [email protected] > > > >> Thanks, > >> washam > >> > >> 2010/10/12 Templin, Fred L <[email protected]>: > >> > Hi Washam, > >> > > >> >> -----Original Message----- > >> >> From: Washam Fan [mailto:[email protected]] > >> >> Sent: Monday, October 11, 2010 7:38 PM > >> >> To: Templin, Fred L > >> >> Cc: Rémi Després; Softwires; [email protected] > >> >> 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 > >> > [email protected] > >> > > >> >> Thanks, > >> >> washam > >> >> > >> >> 2010/10/12 Templin, Fred L <[email protected]>: > >> >> > Remi, > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Rémi Després [mailto:[email protected]] > >> >> >> Sent: Monday, October 11, 2010 10:05 AM > >> >> >> To: Templin, Fred L > >> >> >> Cc: Washam Fan; Softwires; [email protected] > >> >> >> 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 > >> >> > [email protected] > >> >> > > >> >> >> RD > >> >> > > >> >> > >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
