Tom, thanks, apologies for the delay, I've incorporated your suggested changes.
Best, Ole On Jan 27, 2013, at 3:24 , Tom Taylor <[email protected]> wrote: > Here is my suggested change. Most of the text is the same as now, just > rearranged. > > 4. Architecture > > In accordance with the requirements stated above, the MAP mechanism can > operate with shared IPv4 addresses, but also with full IPv4 addresses and > IPv4 prefixes. Operation with shared IPv4 addresses is described now, and the > differences for full IPv4 addresses and prefixes are described below. > > The MAP mechanism uses existing standard building blocks. The > existing NAPT on the CE is used with additional support for > restricting transport protocol ports, ICMP identifiers and fragment > identifiers to the configured port set. For packets outbound from the > private IPv4 network, the CE NAPT MUST > translate transport identifiers (e.g. TCP and UDP port numbers) so > that they fall within the CE's assigned port-range. > > The NAPT MUST in turn be connected > to a MAP aware forwarding function, that does encapsulation/ > decapsulation of IPv4 packets in IPv6. MAP supports the > encapsulation mode specified in [RFC2473]. In addition MAP specifies > an algorithm to do "address resolution" from an IPv4 address and port > to an IPv6 address. This algorithmic mapping is specified in Section > 5. > > The MAP architecture described here, restricts the use of the shared > IPv4 address to only be used as the global address (outside) of the > NAPT [RFC2663] running on the CE. A shared IPv4 address MUST NOT be used > to identify an interface. While it > is theoretically possible to make host stacks and applications port- > aware, that is considered too drastic a change to the IP model > [RFC6250]. > > For full IPv4 addresses and IPv4 prefixes, the architecture just described > applies with two differences. First, a full IPv4 address or IPv4 prefix can > be used as it is today, e.g., for > identifying an interface or as a DHCP pool, respectively. Secondly, the > NAPT is not required to restrict the ports used on outgoing packets. > > This architecture is illustrated in Figure 1. > > > User N > Private IPv4 > | Network > | > O--+---------------O > | | MAP CE | > | +-----+--------+ | > | NAPT44| MAP | | > | +-----+ | |\ ,-------. .------. > | +--------+ | \ ,-' `-. ,-' `-. > O------------------O / \ O---------O / Public \ > / IPv6 only \ | MAP | / IPv4 \ > ( Network --+ Border +- Network ) > \ (MAP Domain) / | Relay | \ / > O------------------O \ / O---------O \ / > | MAP CE | /". ,-' `-. ,-' > | +-----+--------+ | / `----+--' ------' > | NAPT44| MAP | |/ > | +-----+ | | > | | +--------+ | > O---.--------------O > | > User M > Private IPv4 > Network > > > Figure 1: Network Topology > > > > Just to complete the description of Figure 1: the MAP BR is responsible for > connecting external IPv4 networks to > the IPv4 nodes in one or more MAP domains. > > Tom Taylor > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
