Margaret Wasserman wrote: > > It sounds like we are fairly certain that homes and some small > businesses will be given prefixes longer than /48 by their providers. > Are we also convinced that those small networks will require the address > independence feature provided by NAT66? I guess this question boils > down to whether we expect two (or more) hosts within a small network to > communicate directly with each other using global IPv6 addresses.
... and that those applications and networks cannot reasonably survive an occasional renumbering. I am personally of the opinion that all applications, and all networks, need to be engineered to be able to tolerate an occasional renumbering. But of course this isn't always the case. And renumbering is more difficult to do for large networks than for small ones. For some value of "small" I don't think renumbering is onerous. But even a /52 network can be quite large (assuming networks are delegated on nybble boundaries due to DNS concerns). So I think it's a stretch to assume that any network smaller than /48 will be engineered to tolerate occasional renumbering. I therefore conclude that IF ISPs don't uniformly delegate /48s to enterprise networks, there will be some market demand for IPv6 NATs to provide address independence. It strikes me that one of the outputs of this WG (if formed) might well be a reinforcement of the message that /48 really is a minimum network size (maximum prefix length) for any network of significant size, for reasons not understood when that recommendation was originally made. (note the existence of a tussle between ISPs who might like to make decisions which have the unintended consequence of encouraging NAT, and application developers who bear increased costs as a consequence of those decisions) > If we do need to address prefixes of longer than /48 in NAT66, that is > fairly easy to do. We just need to pick which sacrifices we are willing > to make. I can think of two choices: > > (1) Add the checksum correction to a 2byte portion of the lower 64 bits > when the prefix is longer than /48, thus modifying the IID. This > wouldn't be compatible with (currently unspecified) mechanisms that > require a constant IID, but we would already have that problem with > nodes that generate privacy addresses. > > or > > (2) Fix the UDP or TCP checksum instead of performing the checksum > correction algorithm when the prefix is longer than /48. The cost here > is that we lose the ability to encrypt/protect the transport layer > headers. In NAT66, we could explicitly make this correction for UDP/TCP > only, passing through other transport layers unmodified, which might > help to reduce the impact on new innovations at the transport layer. > I think it's going to be difficult to insist that every use of IPv6 NAT is one where the prefix is /48 or shorter. Clearly there's an advantage in doing the checksum correction in the address when feasible, but I doubt it's always going to be feasible. But we won't know for sure until we enumerate all of the use cases and clearly establish which ones have merit. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
