Le mardi 4 août 2009 22:42:12 Margaret Wasserman, vous avez écrit : > On Aug 3, 2009, at 5:15 PM, Rémi Denis-Courmont wrote: > >> (1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable > >> choice for LISP encapsulation? When we looked into this for CAPWAP > >> (another IP-in-UDP/IP tunneling case), we found that UDP-Lite would > >> meet our needs for IPv6, so we did not need to specify the use of > >> zero > >> UDP checksums. > > > > You would expect 64-translators to convert UDP-Lite/IPv6 into UDP- > > Lite/IPv4 > > and back. Converting UDP-Lite/IPv6-with-8-bytes-coverage into UDP/ > > IPv4- > > without-checksum sounds hackish :( > > Are we actually expecting 64-translators to exist between LISP routers?
No idea - apparently not. But it seemed like it would be the case for AMT (so was it implied at the SF IPv6 wg meeting). > In the more general sense, this is something you need to deal with, > because there are things out there that use UDP-Lite. I don't see the > transform you have suggested as any worse than just dropping the IP > header checksum when converting from IPv4 to IPv6 in cases where it is > not covered by a transport layer checksum. The transform is bad. What if you actually want to convert UDP-Lite/IPv6 into UDP-Lite/IPv4? This seems like the natural thing to do. Then how would NAT64s know whether to translate UDP-Lite/IPv6 with 8-bytes coverage into checksum- less UDP/IPv4 or into UDP-Lite/IPv4 with 8-bytes coverage? If we actually except valid use cases of checksum-less UDP/IPv4 to hit NAT64s, then I'd argue a new over-IPv6-only transport protocol is needed. UDP-Lite does not fit precisely because it already exists over IPv4. It would not be the first non-IPv4 next header number. Sure, if we expect that neither LISP, nor AMT, nor any other user of checksum- less UDP/IPv4 to be protocol-translated, then this is a non-issue. Then LISP and AMT and whatever can use UDP-Lite. > >> (2) IP-in-IPv6: Why do you need the UDP encapsulation at all in > >> IPv6? In IPv4, you may need it for NAT traversal, but it is not > >> clear > >> that NATs will work the same way in IPv6. Or are there other reasons > >> why you need the UDP encapsulation? > > > > (...) > > > > Same problem. 64-translators would translate IP-in-IPv6 to IPIP and > > vice > > versa. IPIP does not go through NATs. > > So, now we're running encapsulation protocols behind an IPv4 NAT _and_ > a 64-translator? Ick. Well, I definitely expect that, if NAT64 become widely deployed, we will see IPv4 firewalls or even IPv4 NATs on the IPv4 side of those. > > That's why I was trying to suggest defining a new UDP-Lite-like > > transport > > protocol that would only be allowed over IPv6 and that 64-translator > > would > > convert into checksum-less UDP/IPv4. > > Why is the current UDP-Lite protocol not okay for this? I assume that NAT64s are used. Not that I plan to use them myself. But that "reason" was invoked against UDP-Lite when the troll started in IPv6 wg meeting in San Francisco, when Marshall presented his draft. The reasoning was that UDP-Lite/IPv6 would be 64-translated to UDP-Lite/IPv4, yet UDP-Lite/IPv4 is too poorly supported by the IPv4 infrastructure (firewall and NATs). If everybody now agrees that this is a non-issue, fine with me. -- Rémi Denis-Courmont http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
