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

From: Tom Taylor <[email-masked]>
Date: Sat, 26 Jan 2013 21:24:32 -0500

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