Subject: [rrg] Tutorials on Future Internet

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 16 Sep 2009 12:16:10 +0200

Hello,

There have been lots of discussion in RRG concerning issues related to
the future Internet architecture. During the last week of August, we
organised in the framework of the Trilogy project a summer school
dedicated to this topic. The scientific program contained both poster
sessions and long tutorials by renowned experts :

Paul Francis (MPI-SWS) - Dirty-slate approaches to scaling global
Internet routing
Lars Eggert (Nokia) - Standardization Activities in the IETF/IRTF
Janardhan Iyengar (Franklin & Marshall College) - Rethinking Transport
Layering
Bruno Quoitin (UCL) & Cristel Pelsser (IIJ) - Realistic interdomain
routing simulations with C-BGP and Igen
Bob Briscoe (BT-Network Research Center) - Practical Microeconomics and
Internet Resource Sharing Protocols
Olivier Bonaventure (UCL) - Scaling the Internet with the
Locator/Identifier Separation Protocol (LISP)
Mathieu Lacage (INRIA) - Network experimentation and simulation with ns-3
Timothy Griffin (Cambridge University) - From Semirings to Metarouting
Dimitri Papadimitriou (Alcatel-Lucent) - Compact Routing: Challenges,
Perspectives, and Beyond

All these presentations were recorded and we are happy to announce that
they are now available from  :

	http://inl.info.ucl.ac.be/TFISS09

Best regards,

Olivier Bonaventure

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Sep 2009 15:01:08 -0700

Hi,

I think it should be obvious from the discussions on this
and other lists that the mapping considerations for any
map/encaps scheme are the hard part. I think this has been
known for a very long time, and I'm sure there are folks
watching these discussions who are seeing issues rehashed
that they have known about for years. As such, it might be
worth considering whether a stateless mapping capability
is possible.

As it turns out, for IPv6-in-IPv4 encapsulation a stateless
mapping is possible when the IPv6 EID address embeds the
IPv4 RLOC address. This is the case for schemes such as
6to4, 6rd and isatap. 6to4 in particular was designed to
support router-to-router tunneling between DFZ routers,
where the ITR can determine the ETR's RLOC through a simple
stateless extraction of the RLOC from the EID. This eliminates
the needs for a mapping database, delaying or dropping initial
packets, alternate topologies, and other cumbersome aspects
associated with stateful mapping. So, it might be worth asking
whether a stateless mapping scheme such as 6to4's could be used.

AFAICT, there are only a few aspects of 6to4 that would limit
its applicability as a general solution for EID/RLOC separation
in the DFZ. First, 6to4 uses a well-known prefix (WKP) that is
rather long if the intention were to use it as the primary
routing and addressing mechanism for IPv6 in the Internet DFZ.
In particular, 2002::/16 occupies only 1/2^16th of the total
IPv6 address space, which means that the rest of the space would
expect to use some other form of IPv6 routing and addressing.
This may have been an artifact of the original 6to4 design goal
of providing only a transition mechanism. But, now that we are
seeing proposals to have map/encaps solutions as a core aspect
of routing and addressing in the Internet it may be worth
revisiting those earlier assumptions.

Secondly, each 6to4 IPv6 EID prefix is tied to a single IPv4
RLOC address. This means that if the IPv4 RLOC is down, then
the entire IPv6 EID prefix is unreachable. It may be that a
multi-addressing scheme would be able to switch gracefully
between multiple IPv6 EID prefixes when one goes down, but
there are obvious interactions for mobility, session
continuity, etc. that would tend to favor a stable and
highly-available IPv6 prefix.

Thirdly, the ip-proto-41 encapsulation used by 6to4 may have
suboptimal interactions with core Internet gear that expects
to see only certain IP protocols. Additionally, there is no
nonce field nor a bit field for negotiations between the ITR
and ETR (e.g., an acknowledgement request bit).

It should be easy to see that these shortcomings could be
addressed through minor augmentations to the original 6to4
design (for now we can call it '6to4++') to allow for both
stateless mapping and more robust communications. First, a
much shorter IPv6 well-known prefix 'WKP::/N' could be
procured for this stateless mechanism when a small value for
N is chosen. When concatenated with the 32-bit IPv4 RLOC as
'WKP:V4ADDR::/(N+32)' this would still give a very short
prefix to each holder of a public IPv4 address.

Secondly, prefix availability could be greatly enhanced if
multiple site border routers configured 'V4ADDR' as an IPv4 
anycast address such that there would be multiple ETRs
available for each IPv6 prefix. In that case, IPv4 routing
in the DFZ would direct packets to the nearest available ETR.

Finally, the WKP would serve as an indication that a new
encapsulation format IPv6-in-(foo)-in-IPv4 is to be used.
The (foo) layer could look very much like LISP, SEAL, etc.
and it could contain nonces, bitfields, etc. that would
make communications between the ITR and ETR more robust.
The (foo) layer would also give a handle for the ETR to
provide path MTU feedback to the ITR with a useable nonce.

In general, I believe that the larger the mapping domain
the more cumbersome stateful mapping becomes and the more
beneficial stateless mapping becomes. As such, it might
be worth considering whether a stateless mapping system
via '6to4++' could be used in the Internet DFZ core.

Any thoughts?

Fred
[email-masked]