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

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

On 2011-01-13 21:41, Rémi Després wrote:
> 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

Yes, i.e. connections initiated from the inside. Such companies
normally have their public-facing servers outside the main border,
in a "demilitarized zone".

> - without TCP continuity in case of failure an ISP access being used.

Correct. This was IMHO the big requirement introduced by RFC 3582.
I thought it was a mistake at the time, but I was only the WG Chair
and the consensus was to make it a requirement.

> => incompatible with SHIM6 or SCTP, whose functions include incoming connectivity and TCP continuity.

The incompatibility is exactly as discussed in the Huitema draft I
mentioned, and possibly solved by proxy shim6.

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

Yes.

    Brian

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