Subject: Re: [Softwires] Suggested modifications to Section 4 of draft-ietf-softwire-map-03

From: Ole Troan <[email-masked]>
Date: Tue, 5 Feb 2013 14:49:15 +0100

Tom,

thanks, apologies for the delay, I've incorporated your suggested changes.

Best,
Ole

On Jan 27, 2013, at 3:24 , Tom Taylor <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/softwires