[RRG] basic considerations for map-and-encaps schemes

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

I see some of the map-and-encaps schemes being talked about as
scratching the surface and in the early phases. I believe the
following basic considerations should be addressed in any
map-and-encaps scheme:

1) The locator address space and identifier address space need to be
   kept separate from the start. IPvLX already accomplishes this by
   using globally routable IPv4 addresses as locators and global IPv6
   addresses as identifiers, i.e., the address spaces are kept separate.

2) Any map-and-encaps scheme will need to deal with the fact that
   IPv4 NATs are widely deployed and that is not likely to change
   in the near future. Therefore, the map-and-encaps scheme will
   need to deal with NAT traversal in the first iteration as IPvLX
   already does.

3) Since the tunnels created by map-and-encaps conceal an entire
   path within what appears as a single link to IP, path MTU
   assurance is necessary to avoid sending packets into a black
   hole over a link that cannot be diagnosed. A companion draft
   to IPvLX specifies a path MTU assurance mechanism for the ingress
   tunnel endpoint to get authenticated and reliable feedback from
   the egress tunnel enpoint.

4) The ingress/egress tunnel endpoints should be able to be located
   either in a network middlebox or on the source and/or destination
   end nodes themselves, e.g., when the end hosts also act as routers.
   IPvLX is flexible to allow for any and all deployment alternatives.

5) Sites that deploy a map-and-encaps scheme should implement an
   autoconfiguration scheme that allows end devices to configure
   identifiers, and routers to configure locators with little/no
   manual intervention. A companion draft to IPvLX specifies this
   function.

These are just a few of the basic considerations that are already
covered by IPvLX; the draft also discusses other considerations.
Please review and comment on the draft (see: http://ipvlx.net).

Fred
fred.l.templin@boeing.com    

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg