Sprint IPv6

[Truman Boyes]

This issue that you describe is not specific to IPv6, but rather is an  
issue with any networks that use MPLS VPNs, and do not propagate TTL.  
When providers put the "internet" table into VRFs that same issue is  
presented, and there are *many* ISPs that have decided to carry inet  
routes into VPNs for various reasons.

As you pointed out there are complications with doing this; but 6PE  
doesn't have to "hide" the hops of the MPLS core. It just happens to  
be a method that providers have adopted. The previous statement around  
"normal tunnels" being detected by IGP would stand true with MPLS  
networks as well, assuming the IGP is being used simply to provide  
reachability to loopback addresses, and tunnels are constructed  
between loopbacks, and routes are solved to tunnel interfaces. Its  
recursion, but it all comes back to normal IP hops.

Truman

On 2/10/2008, at 5:18 AM, Gert Doering wrote:

> Hi,
>
> On Thu, Oct 02, 2008 at 10:53:56AM +0200, Jeroen Massar wrote:
>> Bonness, Olaf wrote:
>> [..]
>>> But this seems true for all tunneling techniques and not only for
>>> 6PE or am I misssing something?
>>
>> I guess, the 'using it' factor is what you are missing? :)
>>
>> Traceroutes work like a charm for proto-41, ayiya, openvpn, tinc,
>> everything else I can name....
>
> Well, actually, it doesn't.  You can see "before the tunnel it's fast,
> after the tunnel, it's slow" - but there is no way to figure out
> at which point of the underlying non-tunneled infrastructure the  
> bottleneck
> might be.
>
> Gert Doering
>        -- NetMaster
> -- 
> Total number of prefixes smaller than registry allocations:  128645
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner- 
> Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279