Re: [Int-area] e2e Address transparency - PI site routing - Multi-CPE multihoming

[Brian E Carpenter <[e-mail]>]

I hate to have to say this, but the reason that NAT44 became popular for
quite a number of large (typically multinational) enterprise networks
was as the easiest solution to the multi-exit problem. These companies
didn't regard NAT as a security feature; they had firewalls for that.
And they didn't *want* to lose address transparency; that was considered
an acceptable side-effect of gaining a solution to the multi-exit
multi-homing problem.

Also look in your time machine for
"Ingress filtering compatibility for IPv6 multihomed sites"
draft-huitema-multi6-ingress-filtering-00

Regards
   Brian Carpenter

On 2011-01-13 05:20, Rémi Després wrote:
> Alberto,
> 
> Thank you for this interesting reference I hadn't noticed.
> 
> It did share the objective of combining of "PI site routing" with "Multi-CPE multihoming", but was NOT concerned with "e2e address transparency".
> 
> Besides:  
> - It needed a middle-box between all hosts and CPE's
> - It needed a new DNS RR type.
> Both have to be avoided in the solution I look for.
> 
> Kind regards,
> RD
> 
> 
> 
> Le 12 janv. 2011 à 11:52, Alberto García a écrit :
> 
>> Hi,
>> The requirements you state remind me the Proxy Shim6 proposal
>> (http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is also a
>> paper on the subject at
>> http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf
>> The abstract of the paper says:
>> "The P-SHIM6 architecture provides ISP independence to IPv6 sites without
>> compromising scalability.
> 
>> This architecture is based on a middle-box, the
>> P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the nodes of
>> a site, which are configured  with provider independent addresses. Incoming
>> and outgoing packets are processed by the P-SHIM6 box, which can assign
>> different locators to a given communication, either when it is started, or
>> dynamically after the communication has been established. As a consequence,
>> changes required for provider portability are minimized, and fine-grained
>> Traffic Engineering can be enforced at the P-SHIM6 box, in addition to the
>> fault tolerance support provided by SHIM6."
>>
>> Regards,
>> Alberto
>>
>> |  -----Mensaje original-----
>> |  De: [e-mail] [mailto:[e-mail]] En
>> |  nombre de Rémi Després
>> |  Enviado el: miércoles, 12 de enero de 2011 11:19
>> |  Para: Brian E Carpenter
>> |  CC: Internet Area
>> |  Asunto: [Int-area] e2e Address transparency - PI site routing - Multi-CPE
>> |  multihoming
>> |  
>> |  Brian,
>> |  
>> |  Here is a good opportunity to clarify an important point, on which I hope
>> we
>> |  can converge.
>> |  
>> |  The problem I worked on is how to combine:
>> |  - "e2e address transparency" (hosts know their own global addresses, and
>> |  use them)
>> |  - "PI site routing"  (e.g., in IPv6, ULA-only intra-site routing to avoid
>> |  renumbering problems)
>> |  - "Multi-CPE Multihoming" (the most complete multihoming model).
>> |  - "Per-site incremental deployment" (a site can use the solution
>> |  independently from what is done anywhere else).
>> |  
>> |  - LISP is off-scope because it doesn't permit per-site incremental
>> |  deployment.
>> |  
>> |  This problem has two complementary sub-problems:
>> |  . "Source-address selection" (how does a host select a particular e2e
>> source
>> |  address for an outgoing packet)?
>> |  . "Outgoing-CPE control" (the source address being selected, how to
>> ensure
>> |  that the packet goes via the right CPE)?
>> |  - Solutions for "source-address selection" do exist (SHIM6, SCTP,
>> draft-ietf-
>> |  v6ops-multihoming-without-nat66).
>> |  - AFAIK, a solution for "outgoing-CPE control" in the above context still
>> has
>> |  to be specified
>> |  
>> |  The key I briefly described for this "outgoing-CPE selection", in sec 3.3
>> of
>> |  draft-despres-softwire-sam-01), is that:
>> |  - For customer-site traversal, hosts encapsulate e2e packets in local
>> packets
>> |  (IPv6/IPv6).
>> |  - Hosts address these local packets to the right CPE's by using a
>> |  correspondence list between local CPE addresses and global IPv6 prefixes.
>> |  
>> |  Unless this is proved to be useless, I plan to pursue in this direction,
>> with
>> |  whoever is interested in making positive contributions.
>> |  
>> |  Best regards,
>> |  RD
>> |  
>> |  
>> |  
>> |  Le 11 janv. 2011 à 21:30, Brian E Carpenter a écrit :
>> |  >> ... it should be more useful to look for solutions that combine
>> provider
>> |  independence with address transparency, than accepting without effort to
>> |  sacrifice address transparency for provider independence.
>> |  >
>> |  > Indeed; we already have one of those standardised, which also has the
>> |  > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC
>> 5535.
>> |  
>> |  (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about securing
>> |  multihoming address sets. None of these addresses the "outgoing-CPE
>> |  control" issue).
>> |  
>> |  
>> |  _______________________________________________
>> |  Int-area mailing list
>> |  [e-mail]
>> |  https://www.ietf.org/mailman/listinfo/int-area
>>
> 
> 
>