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

[Rémi Després <[e-mail]>]

Thank you, Brian, for this other interesting reference I hadn't noticed.


Le 12 janv. 2011 à 22:23, Brian E Carpenter a écrit :

> 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.

I agree, but, in my understanding:
- only for outgoing connectivity
- without TCP continuity in case of failure an ISP access being used.
=> incompatible with SHIM6 or SCTP, whose functions include incoming connectivity and TCP continuity.

> 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.

That's why, IMHO, an IPv6 solution that avoids this side-effect is worth working on.

Regards,
RD 


> 
> 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
>>> 
>> 
>> 
>> 
>