Re: (ngtrans) draft-lefaucheur-bgp-tunnel-transition-00.txt

[Ole Troan <[e-mail]>]

> 	i don't understand why this transition technology is needed.
>
> 	to make use of this mechanism, we need to upgrade all of the EBGP
> 	routers in the cloud.  when doing so, we can setup normal RFC2893
> 	tunnels and do normal BGP4+ over IPv6 (over IPv6-over-IPv4 tunnel).
> 	we don't need a new automated mechanism.

I believe the motivation here is for the operator who do not want to
maintain a full mesh of configured tunnels in addition to the BGP
mesh. looking at the scenario 1, note that there is no magic. the
next-hop carried in BGP is one matching whatever automatic tunnelling
mechanism chosen. as far as I know all current BGP/IPv6
implementations already support this.

> 	another thing bothers me is the special use of IPv4 mapped address
> 	as indication of tunnel endpoint.  IPv4 mapped address already has
> 	overloaded with multiple meanings (RFC2553 API, SIIT, ...) and i
> 	really want to see these multiple semantics get removed, and make it
> 	be used only for RFC2553 only.  it causes a lot of security issues
> 	as outlined in my previous drafts.
> 	(i'm happy to say long good bye to IPv4 mapped address itself, but that
> 	is another question)
>
> 	we don't need more magic.

the scenario 1 offers a solution where you use IPv6 in IPv4 tunnelling
to create IPv6 connectivity. scenario 2 does not give IPv6
connectivity until your BGP sessions are up. this allows you to e.g
use this mechanism to encapsulate IPv6 packets in MPLS without an
additional IPv4 header or IPv6 IGP in the core.

cheers,
Ole