If those interim hops are IPv4 only nodes part of 6/PE there could be a few things going on here.
1) Juniper u-RPF for family inet6 drops the mapped-v4-v6 source packets generated by a P/PE router
2) FreeBSD (8.2 at least) doesn't seem to like mapped-v4-v6 source packets with its default traceroute (same for mtr on FreeBSD)
(tcpdump will show you the packets coming back, the freebsd traceroute6 seems to have a few unresolved bugs.. you need to force -w 1 as well likely)
3) If end-to-end connectivity works,
Workarounds:
the IPv4 only P/PE device should have some sort of IPv6 address placed on transit interfaces to allow TTL expired to be sourced from something capable (this IP doesn't need to be able to be reached/routed to that interface, just exist).
I spent a lot of time looking at a similar problem and it ended up being a combination of #1 & #2 above. You will see this problem across The AT&T and Cogent networks in my experience.
In message <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net>, Jared Mauch w
rites:
If those interim hops are IPv4 only nodes part of 6/PE there could be a =
few things going on here.
1) Juniper u-RPF for family inet6 drops the mapped-v4-v6 source packets =
generated by a P/PE router
2) FreeBSD (8.2 at least) doesn't seem to like mapped-v4-v6 source =
packets with its default traceroute (same for mtr on FreeBSD)
(tcpdump will show you the packets coming back, the freebsd traceroute6 =
seems to have a few unresolved bugs.. you need to force -w 1 as well =
likely)
I see nothing in tcpdump other than the outgoing traffic and the replies
already noted.
3) If end-to-end connectivity works,=20
Workarounds:
the IPv4 only P/PE device should have some sort of IPv6 address placed =
on transit interfaces to allow TTL expired to be sourced from something =
capable (this IP doesn't need to be able to be reached/routed to that =
interface, just exist).
I spent a lot of time looking at a similar problem and it ended up being =
a combination of #1 & #2 above. You will see this problem across The =
AT&T and Cogent networks in my experience.
Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft out there that talks about this as well but don't have a pointer to it. It is true that if an MPLS-LSR/P device does not understand the IPv6 frame you will see no response for that TTL. It's only the P devices that do understand an IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message.
The real questions are:
1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these packets? (and if they are, are you requesting they make this change?)
2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest?
3) should operators of IPv6 capable equipment be running them in an MPLS-LSR/P role be assigning an IPv6 address on interfaces to provide a valid source-address even if they are not reachable in return? Should the vendor provide a knob to generate the ttl expiry messages from some other source address, obscuring the interface IPs involved (such as a loopback)?
Mark, it may also be valuable to see testing from a server at ISC that doesn't transit HE to reach the ATT network. While you still can't see who is dropping your packets, you may find someone who doesn't have loose-rpf enabled and observe some of the other behaviors noted.
- Jared
(BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devices)
the IPv4 only P/PE device should have some sort of IPv6 address placed =
on transit interfaces to allow TTL expired to be sourced from something =
capable (this IP doesn't need to be able to be reached/routed to that =
interface, just exist).
I spent a lot of time looking at a similar problem and it ended up being =
a combination of #1& #2 above. You will see this problem across The =
AT&T and Cogent networks in my experience.
The path is going through AT&T.
Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft out there that talks about this as well but don't have a pointer to it. It is true that if an MPLS-LSR/P device does not understand the IPv6 frame you will see no response for that TTL. It's only the P devices that do understand an IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message.
The real questions are:
1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these packets? (and if they are, are you requesting they make this change?)
We aren't doing loose-rpf on ISC's transit session (for the reason you stated and others).
2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest?
3) should operators of IPv6 capable equipment be running them in an MPLS-LSR/P role be assigning an IPv6 address on interfaces to provide a valid source-address even if they are not reachable in return? Should the vendor provide a knob to generate the ttl expiry messages from some other source address, obscuring the interface IPs involved (such as a loopback)?
Mark, it may also be valuable to see testing from a server at ISC that doesn't transit HE to reach the ATT network. While you still can't see who is dropping your packets, you may find someone who doesn't have loose-rpf enabled and observe some of the other behaviors noted.
The problem observed also happens for native IPv6 packets sent to 2001:1890:1112:1::1e
We can confirm the packets leave our network and are handed off to the correct party.
We've sent emails regarding this to the other parties involved with no response so far. I'll make sure people start getting phone calls.
>
>>> 3) If end-to-end connectivity works,=20
>>>
>>> Workarounds:
>>>
>>> the IPv4 only P/PE device should have some sort of IPv6 address placed =
>>> on transit interfaces to allow TTL expired to be sourced from something =
>>> capable (this IP doesn't need to be able to be reached/routed to that =
>>> interface, just exist).
>>>
>>> I spent a lot of time looking at a similar problem and it ended up being =
>>> a combination of #1& #2 above. You will see this problem across The =
>>> AT&T and Cogent networks in my experience.
>> The path is going through AT&T.
> Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft
out there that talks about this as well but don't have a pointer to it. It i
s true that if an MPLS-LSR/P device does not understand the IPv6 frame you wil
l see no response for that TTL. It's only the P devices that do understand an
IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message.
>
> The real questions are:
>
> 1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these p
ackets? (and if they are, are you requesting they make this change?)
We aren't doing loose-rpf on ISC's transit session (for the reason you
stated and others).
> 2) is a mapped-v4 address a valid *source* address on the wire even if it's
not a valid dest?
> 3) should operators of IPv6 capable equipment be running them in an MPLS-LSR
/P role be assigning an IPv6 address on interfaces to provide a valid source-a
ddress even if they are not reachable in return? Should the vendor provide a
knob to generate the ttl expiry messages from some other source address, obscu
ring the interface IPs involved (such as a loopback)?
>
> Mark, it may also be valuable to see testing from a server at ISC that doesn
't transit HE to reach the ATT network. While you still can't see who is drop
ping your packets, you may find someone who doesn't have loose-rpf enabled and
observe some of the other behaviors noted.
The problem observed also happens for native IPv6 packets sent to
2001:1890:1112:1::1e
We can confirm the packets leave our network and are handed off to the
correct party.
We've sent emails regarding this to the other parties involved with no
response so far. I'll make sure people start getting phone calls.
Mike.
Thanks.
I wasn't trying to complain about HE's support, which has always
been good. I was trying to point out the not having working time
exceeded messages makes everybody's job harder. That it is time
to take IPv6 seriously and part of doing that means making sure
that error reporting works.
mapped-v4 and 1918 addresses are valid in that both meet the address format constraints.
technically they work as both source and destination - the restriction is administrative.
