Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification. We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was "they do not route network smaller than a /32". Fair enough... capacity planning for all the /48's would give a router a headache with today's hardware... so we requested address delegated from Verizon's larger block of addresses to be used for addressing. The response was that we could not receive new address space until we returned our ARIN provided address space... so in effect, go back and get a /32 from ARIN or give up on ever owning address space again. ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32. revo
Robert.E.VanOrmer@frb.gov wrote:
Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification.
There are a bunch of IXPs around who have been announcing /48s for a some while. From a cursory glance around, it looks like Verizon is unreachable from these at least AS2128, which announces a single /48. This would seem to support your sales person's claim. It will be interesting to see how long this policy lasts - or at least it will be interesting to see at what stage carriers decide that the loss in sales revenues hurts more than the cost of carrying /48s from PI delegatin blocks. Nick
From: Robert.E.VanOrmer@frb.gov Date: Mon, 17 Nov 2008 16:46:08 -0600
Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification.
We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was "they do not route network smaller than a /32". Fair enough... capacity planning for all the /48's would give a router a headache with today's hardware... so we requested address delegated from Verizon's larger block of addresses to be used for addressing. The response was that we could not receive new address space until we returned our ARIN provided address space... so in effect, go back and get a /32 from ARIN or give up on ever owning address space again.
ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32.
Lots of people have /48s from ARIN and many are routed. The global IPv6 table currently has about 200 of them. Among those using /48s are ARIN and at least three of the root name servers, so that policy would block access to rather important sites. :-) I'd say that someone at VZB is pretty clueless. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On 11/17/08 14:46, Robert.E.VanOrmer@frb.gov wrote:
ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32.
You may want to post this issue to the ARIN PPML list (see http://www.arin.net/mailing_lists/index.html if you're not already subscribed), as that might be a useful venue for discussion as well. You're right in noting that this is a catch-22. ARIN and other RIRs are now giving out PI /48s, but there is still a notion that /32 is considered the maximum routable prefix length. However, UCB sees a lot of globally-routed /48s (and /35s, /40s, etc.) in our DFZ routing table. (I also see some /48s disaggregated from a /32 and announced in at least one non-ARIN region, but I am sure this is happening elsewhere. :-( ) So, I do think that /48 is beginning to be the new /32 when it comes to prefix filtering, but I can also understand those who want to hold to the more strict IPv6 filtering policies. I think in the end, we are going to end up generally accepting up to /48s. Basically, we're going to break the routing table anyway--the number of potential /32s is more than enough to do that, and forcing everyone who: a. needs to be multi-homed; and b. needs more than 1-2 subnets to get a /32 has to be a waste, no matter how big the potential address space is overall. One compromise would be to require that blocks that can be aggregated be aggregated, and then allow PI /48s. In theory, this could be enforced a number of ways, but I am sure we're all aware of how well that works... michael
On 2008-11-17, at 17:46, Robert.E.VanOrmer@frb.gov wrote:
Are there any parties out there routing /48 IPv6 networks globally?
Yes. Some particularly visible examples are root and TLD server operators. There are some TLDs which are well-served by IPv6-capable nameservers, but which would be completely invisible to v6-only clients if their covering /48s were not accepted. ASes which refuse prefixes longer than 32 bits across the board as a matter of policy are broken. The last time I looked, the RIRs with v6 micro-assignment policies were all doing long-prefix assignments from an easy-to-identify range of addresses. Creating a general-purpose filter which lets through PI / 48s but drops PA/deaggregated /48s is not rocket science.
I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification.
I was once told by another large carrier I was trying to buy from in Miami that "you are not allowed to announce your own addresses in IPv6; you have to use addresses from your upstream". While the goal of encouraging use of PA addresses and discouraging deaggregation may be noble and good, it seems more education is required in some areas. "There is such a thing as PI in IPv6", for example, and perhaps "just because it's a /48 doesn't mean it's not PI". Joe
On Nov 17, 2008, at 3:47 PM, Joe Abley wrote:
The last time I looked, the RIRs with v6 micro-assignment policies were all doing long-prefix assignments from an easy-to-identify range of addresses. Creating a general-purpose filter which lets through PI /48s but drops PA/deaggregated /48s is not rocket science.
As of June, 2008, at least, AfriNIC was not using a distinct range for these. There was discussion of converting to this due to these problems.
Owen DeLong wrote:
As of June, 2008, at least, AfriNIC was not using a distinct range for these. There was discussion of converting to this due to these problems.
afrinic /48 are out of 2001:43f8::/29 http://www.afrinic.net/Registration/resources.htm grep -w ipv6 delegated-afrinic-20081118 | grep -w 48 afrinic|TZ|ipv6|2001:43f8::|48|20070711|assigned afrinic|KE|ipv6|2001:43f8:10::|48|20070713|assigned afrinic|ZA|ipv6|2001:43f8:20::|48|20070726|assigned afrinic|ZA|ipv6|2001:43f8:30::|48|20070730|assigned afrinic|ZA|ipv6|2001:43f8:40::|48|20070921|assigned afrinic|ZA|ipv6|2001:43f8:50::|48|20071029|assigned afrinic|KE|ipv6|2001:43f8:60::|48|20080411|assigned afrinic|NA|ipv6|2001:43f8:80::|48|20081107|assigned Frank
On 18/11/2008, at 11:46 AM, [1]Robert.E.VanOrmer@frb.gov wrote: We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was "they do not route network smaller than a /32". I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with /48s assigned[1] from that - or something like that. IXP space was mentioned.. I'm not sure that needs to be globally reachable. Maybe to stop uRPF breaking ICMP messages if routers on the exchange respond from their interface address.. though.. I'd prefer to make my routers respond from loopback or something. -- Nathan Ward [1] Maybe I mean allocated, whatever. -- Nathan Ward References 1. mailto:Robert.E.VanOrmer@frb.gov
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either. vzb's v6 table is far from complete :( which is pretty painful. -chris
On 11/18/08 9:26 AM, Christopher Morrow wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www. michael
Michael Sinatra wrote:
On 11/18/08 9:26 AM, Christopher Morrow wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
oddly enough I kind of expect my settlement free upstream to have somewhat fewer routes than say those tier-2s that I also buy transit from.
michael
On Tue, Nov 18, 2008 at 12:39 PM, Michael Sinatra <michael@rancid.berkeley.edu> wrote:
On 11/18/08 9:26 AM, Christopher Morrow wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
if you want v6 adoption... latency, path length, jitter, performance all should closely match v4 specs. Expecting a US customer to be 'ok' with 300ms to reach a US site 30 miles (as the crow flies) via Germany... not good. V6 so far doesn't have the same $$ and interest from the 'user' so it's not being optomized yet. Or so it seems. -chris
Christopher Morrow wrote:
if you want v6 adoption... latency, path length, jitter, performance all should closely match v4 specs. Expecting a US customer to be 'ok' with 300ms to reach a US site 30 miles (as the crow flies) via Germany... not good.
V6 so far doesn't have the same $$ and interest from the 'user' so it's not being optomized yet. Or so it seems.
Until the peering topology of v6 matches v4, we will continue to see this issue. I expect to wait until the last minute when the NSP's suddenly realize that they need to switch, and as my dual stack peerings increase, so will the QOS. At that point, the content providers will add AAAA and the eyeball networks will have the worst of it. M$ seems to be coming along fine with IPv6, but the problem we'll see is all those modems/routers which do not support it and probably can't with the minimal flash space they have. I haven't even seen good alternatives yet to start pushing my customers into IPv6 routers. Jack
Michael Sinatra wrote:
On 11/18/08 9:26 AM, Christopher Morrow wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
Having no route is not a problem, you should get a destination unreachable directly and all is fine because IPv4 should be used as a fallback. The biggest issue at the moment with IPv6 for endusers is broken DNS caches/forwarders that just drop AAAA queries and thus let the client timeout and then optionally fallback to IPv4. Wikimedia has also been doing tests like the Google one already for some while, their results are publicly available here: http://ipv6and4.labs.wikimedia.org/ Greets, Jeroen (notice my usage of 'should' here, because other issues will break things too ;)
Having no route is not a problem, you should get a destination unreachable directly and all is fine because IPv4 should be used as a fallback.
The big problem is when you have a route to them, but they don't have a route back. You don't get destination unreachables, but instead get timeouts, and pain, and misery (btdt). :(
On 11/18/08 9:59 AM, Jeroen Massar wrote:
Michael Sinatra wrote:
On 11/18/08 9:26 AM, Christopher Morrow wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful. And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
Having no route is not a problem, you should get a destination unreachable directly and all is fine because IPv4 should be used as a fallback.
Not all routers send dest unreachable (yes they should). Not all firewalls pass it. And, worst of all, we have even seen OSes that don't pay any attention to dest unreachables and just wait for timeouts. :( Fortunately those latter edge cases seem to be getting fixed, but YMMV. michael
* Michael Sinatra:
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
Won't current Windows clients work just fine in this case? I have no idea what a fix should look like for some of the non-Windows systems I care about, unfortunately.
On 20/11/2008, at 4:06 AM, Florian Weimer wrote:
* Michael Sinatra:
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
Won't current Windows clients work just fine in this case?
I have no idea what a fix should look like for some of the non-Windows systems I care about, unfortunately.
No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling back to IPv4/A. Works fine most of the time, however when that non-RFC1918 address is behind NAT, or some sort of packet filter, then it doesn't work so well, and the client does not have a way to detect that reliably. -- Nathan Ward
On Thu, 20 Nov 2008, Nathan Ward wrote:
On 20/11/2008, at 4:06 AM, Florian Weimer wrote:
* Michael Sinatra:
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
Won't current Windows clients work just fine in this case?
I have no idea what a fix should look like for some of the non-Windows systems I care about, unfortunately.
No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling back to IPv4/A.
This must be a broken RFC 3484 implementation: - 6to4 should be less prerefed than IPv4 if the service has both AAAA and A record. Regards, Janos Mohacsi
* Mohacsi Janos:
On Thu, 20 Nov 2008, Nathan Ward wrote:
On 20/11/2008, at 4:06 AM, Florian Weimer wrote:
* Michael Sinatra:
And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www.
Won't current Windows clients work just fine in this case?
I have no idea what a fix should look like for some of the non-Windows systems I care about, unfortunately.
Do you mean that the client tries to enable 6to4 unsuccessfully?
No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling back to IPv4/A.
This must be a broken RFC 3484 implementation: - 6to4 should be less prerefed than IPv4 if the service has both AAAA and A record.
RFC 3848 generally prefers IPv6 over IPv4 and fails if the host running its algorithm has neither IPv6 connectivity nore mean to detect that efficiently. I think Windows does something in the second area.
Florian Weimer wrote: >>> No, unfortunately broken 6to4 auto-configuration (ie, in Vista, >>> XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s >>> timeouts before falling back to IPv4/A. >> This must be a broken RFC 3484 implementation: >> - 6to4 should be less prerefed than IPv4 if the service has both AAAA >> and A record. > > RFC 3848 generally prefers IPv6 over IPv4 and fails if the host > running its algorithm has neither IPv6 connectivity nore mean to > detect that efficiently. I think Windows does something in the second > area. Yes and no. The test that was being run used 6to4 addresses, so every 6to4 capable device did try to reach it via 6to4, since that is preferred over IPv4. If it had used non-6to4 addressing, then IPv4 would had been preferred on those hosts that didn't have non-6to4 addresses. This is one reason why I believe using 6to4 addresses to be an issue for content providers. If they use non-6to4 addressing for the content, then most people will prefer IPv4 except for those who have configured non-6to4 addresses or altered the labels to force 6to4 to work with non-6to4 addressing. Gads, is it appropriate to just say Native when referring to non-6to4? lol Jack
Jack Bates wrote:
..... Yes and no. The test that was being run used 6to4 addresses, so every 6to4 capable device did try to reach it via 6to4, since that is preferred over IPv4. If it had used non-6to4 addressing, then IPv4 would had been preferred on those hosts that didn't have non-6to4 addresses.
This is one reason why I believe using 6to4 addresses to be an issue for content providers. If they use non-6to4 addressing for the content, then most people will prefer IPv4 except for those who have configured non-6to4 addresses or altered the labels to force 6to4 to work with non-6to4 addressing.
Gads, is it appropriate to just say Native when referring to non-6to4? lol
Terminology is a mess, because 2001:: could be tunneled directly from the end system, and 2002:: might be received in an RA by an end system so it doesn't know the difference between that and any other prefix. In any case, content providers can avoid the confusion if they simply put up a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst, while 6to4 connected systems will chose 2002:: as the dst. There is no need to offer transit service to the entire world, and the latency/path selection for 6to4 to their demark will be exactly the same as the IPv4 service. Access providers could offer a localized 6to4 relay by ignoring the comment in the RFC that says 'must advertize 2002::/16', and send the appropriate ~32-40 into the IPv6 routing system that corresponds just to the customers being served by that relay. Yes the IPv6 routing system gets bigger, but there aren't enough people that would consider deploying a 6to4 relay to create a --real-- problem. FUD mongers will scream, but be pragmatic and only announce what is necessary to get some stable service to your customers. Running this service also provides a way to document how many people are using IPv6 despite the lack of availability on the distribution media. Now we get constant reports of no-traffic, because it is bypassing the local ISP monitoring system. On a recent torrent ~ 1/3 of the peers were connecting via IPv6, and most of the content my client exchanged was via those peers rather than the IPv4 ones. Clearly there is traffic, it is just going over the top to work around the lack of the service that is required ... Tony
* alh-ietf@tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]:
In any case, content providers can avoid the confusion if they simply put up a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst, while 6to4 connected systems will chose 2002:: as the dst. There is no need
Huh? Longest match done by web browsers and other applications? Since when? -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian
In message <20081126002425.GO78345@burnout.tpb.net>, Niels Bakker writes:
In any case, content providers can avoid the confusion if they simply put u
* alh-ietf@tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: p
a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst, while 6to4 connected systems will chose 2002:: as the dst. There is no need
Huh? Longest match done by web browsers and other applications? Since when?
FreeBSD 6 has is as part of the standard getaddrinfo() implementation. % grep -r in6_addrpolicy /usr/src/lib/libc /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy pc_policy; /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol, *ep; /usr/src/lib/libc/net/getaddrinfo.c: ep = (struct in6_addrpolicy *)(buf + l); /usr/src/lib/libc/net/getaddrinfo.c: for (pol = (struct in6_addrpolicy *)buf; pol + 1 <= ep; pol++) { /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol; /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy pc_policy; /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol, *ep; /usr/src/lib/libc/net/name6.c: ep = (struct in6_addrpolicy *)(buf + l); /usr/src/lib/libc/net/name6.c: for (pol = (struct in6_addrpolicy *)buf; pol + 1 <= ep; pol++) { /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol; % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
* Mark_Andrews@isc.org (Mark Andrews) [Wed 26 Nov 2008, 01:55 CET]:
In message <20081126002425.GO78345@burnout.tpb.net>, Niels Bakker writes:
* alh-ietf@tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]:
In any case, content providers can avoid the confusion if they simply put up a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst, while 6to4 connected systems will chose 2002:: as the dst. There is no need Huh? Longest match done by web browsers and other applications? Since when? FreeBSD 6 has is as part of the standard getaddrinfo() implementation.
I don't see that do any differentiation between 2001::/32, 2002::/16 and 2000::/8; only between IPv6-mapped IPv4 addresses and various interface/link/site-local addresses. And even that function has a big * XXX: we should standardize the functions and link them as standard * library. warning stuck on top of it -- Niels.
In message <20081126012326.GR78345@burnout.tpb.net>, Niels Bakker writes:
* Mark_Andrews@isc.org (Mark Andrews) [Wed 26 Nov 2008, 01:55 CET]:
In message <20081126002425.GO78345@burnout.tpb.net>, Niels Bakker writes:
* alh-ietf@tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]:
In any case, content providers can avoid the confusion if they simply put up a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst , while 6to4 connected systems will chose 2002:: as the dst. There is no ne ed Huh? Longest match done by web browsers and other applications? Since when? FreeBSD 6 has is as part of the standard getaddrinfo() implementation.
I don't see that do any differentiation between 2001::/32, 2002::/16 and 2000::/8; only between IPv6-mapped IPv4 addresses and various interface/link/site-local addresses. And even that function has a big * XXX: we should standardize the functions and link them as standard * library. warning stuck on top of it
2002::/16 vs non 2002::/16 should be in the policy table. This is the default prefer ipv6 policy table for FreeBSD 6.4-PRERELEASE. There is also a alternate prefer ipv4 policy table that will be set if IPv6 is disabled. Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 4997 2002::/16 30 2 0 ::/96 20 3 0 ::ffff:0.0.0.0/96 10 4 0 Mark
-- Niels. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
* Mark_Andrews@isc.org (Mark Andrews) [Wed 26 Nov 2008, 02:57 CET]:
2002::/16 vs non 2002::/16 should be in the policy table. This is the default prefer ipv6 policy table for FreeBSD 6.4-PRERELEASE. There is also a alternate prefer ipv4 policy table that will be set if IPv6 is disabled.
Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 4997 2002::/16 30 2 0 ::/96 20 3 0 ::ffff:0.0.0.0/96 10 4 0
I believe that is used for local address selection, not for sorting DNS replies. -- Niels.
In message <20081126021519.GT78345@burnout.tpb.net>, Niels Bakker writes:
* Mark_Andrews@isc.org (Mark Andrews) [Wed 26 Nov 2008, 02:57 CET]:
2002::/16 vs non 2002::/16 should be in the policy table. This is the default prefer ipv6 policy table for FreeBSD 6.4-PRERELEASE. There is also a alternate prefer ipv4 policy table that will be set if IPv6 is disabled.
Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 4997 2002::/16 30 2 0 ::/96 20 3 0 ::ffff:0.0.0.0/96 10 4 0
I believe that is used for local address selection, not for sorting DNS replies.
It's used for both.
-- Niels. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
* Mark_Andrews@isc.org (Mark Andrews) [Wed 26 Nov 2008, 03:20 CET]:
It's used for both.
Yet from /usr/src/lib/libc/getaddrinfo.c --- /* Rule 7: Prefer native transport. */ /* XXX: not implemented yet */ --- But it is not used to distinguish between 2001: and 2002: as ::/0 has a higher precedence in the default FreeBSD IPv6 address selection policy table. Where does FreeBSD and by extension KAME get its strong preference for 2001: from? I just can't find the code. (I'm reviving this old thread because you chose to ignore my mail to you but did not fail to reply to a single mail I sent to the list concerning this.) -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian
In message <20081209233310.GY78345@burnout.tpb.net>, Niels Bakker writes:
* Mark_Andrews@isc.org (Mark Andrews) [Wed 26 Nov 2008, 03:20 CET]:
It's used for both.
Yet from /usr/src/lib/libc/getaddrinfo.c --- /* Rule 7: Prefer native transport. */ /* XXX: not implemented yet */ ---
But it is not used to distinguish between 2001: and 2002: as ::/0 has a higher precedence in the default FreeBSD IPv6 address selection policy table. Where does FreeBSD and by extension KAME get its strong preference for 2001: from? I just can't find the code.
(I'm reviving this old thread because you chose to ignore my mail to you but did not fail to reply to a single mail I sent to the list concerning this.)
/* Rule 5: Prefer matching label. */ If you have a 2001 address and the destination has a 2001 and 2002 address the 2001 will sort to the top here. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
* Niels Bakker:
* alh-ietf@tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]:
In any case, content providers can avoid the confusion if they simply put up a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst, while 6to4 connected systems will chose 2002:: as the dst. There is no need
Huh? Longest match done by web browsers and other applications? Since when?
It's been part of GNU libc for a while, but it has been disabled by several distributions. Usually, random selection leads to better results. At they very least, it makes renumbering much simpler because all addresses are equal, independently of where your clients are located. It's been a PITA to get this resolved (both in the IETF and in implementations), and it's still not done AFAIK.
In a message written on Tue, Nov 18, 2008 at 12:26:36PM -0500, Christopher Morrow wrote:
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
It's only "Critical Infrastructure", and there's only like 50 of them now (mostly root servers and CC-Tld's) in the ARIN region. http://www.arin.net/reference/micro_allocations.html Note too that they are not all /48's. A lot of people want to filter the range with le 47 ge 49, and that doesn't work either. F-Root's covering prefix is a /47, for example. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Leo Bicknell wrote:
In a message written on Tue, Nov 18, 2008 at 12:26:36PM -0500, Christopher Morrow wrote:
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
It's only "Critical Infrastructure", and there's only like 50 of them now (mostly root servers and CC-Tld's) in the ARIN region.
And a LOT and LOT more, don't forget the rest of the world please, there is more than the ARIN region, even if this is the NA-nog list ;) Check: http://www.space.net/~gert/RIPE/ipv6-filters.html for a list of suggested filter expressions that cover all of these correctly. From http://www.sixxs.net/tools/grh/dfp/ * 1x /13 * 2x /19 * 6x /20 * 4x /21 * 5x /22 * 1x /23 * 2x /24, 13x returned, 45x reclaimed * 2x /25 * 5x /26 * 4x /27 * 9x /28, 14x returned, 42x reclaimed * 4x /29 * 5x /30 * 3x /31, 1x returned * 2112x /32, 45x returned, 22x reclaimed * 4x /35, 2x returned * 2x /40 * 5x /41 * 1x /42 * 2x /43 * 3x /44, 1x returned * 7x /45 * 7x /46 * 11x /47 * 376x /48, 3x returned * 5x /64 Not everything is a /32 ;) Greets, Jeroen
On Tue, 18 Nov 2008, Jeroen Massar wrote:
Check: http://www.space.net/~gert/RIPE/ipv6-filters.html for a list of suggested filter expressions that cover all of these correctly.
Unfortunately, the JunOS version of the strict filter is blocking /32's from APNIC region as well. The offending lines are: route-filter 2001::/16 prefix-length-range /19-/32; ... route-filter 2001:0c00::/23 prefix-length-range /48-/48; This is because Juniper uses longest prefix matching in route filters (maybe this is different in cisco, I don't know): https://www.juniper.net/techpubs/software/junos/junos92/swconfig-policy/how-... As a result, this will end up rejecting legitimate prefixes such as 2001:c00::/32 because then only /48's are accepted from that range. Unfortunately, I don't know which blocks APNIC has set aside from 2001:0c00::/23 for /48 assignments; based on their web pages, they have policies for at least multihoming, IXs and critical infrastructure. But I couldn't find info which block these are from. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 19/11/2008, at 4:26 AM, Christopher Morrow wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
-chris
of the 1494 entries in the Ipv6 inter-domain routing table that is seen at the Ipv6 route-views router there are 347 /48's (and 1 /56 and 12 /64s, I dunno why) More details at http://bgp.potaroo.net/v6/as6447/ if anyone is interested
On Tue, 18 Nov 2008, Christopher Morrow wrote:
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
That's not all that's broken at vzb. I've been trying to get them to troubleshoot/fix a possible PMTU problem for weeks now. Everytime I try turning up our tunnel with them we lose http connectivity to various web sites (you can still ping/traceroute the same sites) one of which is isc.org. Antonio Querubin whois: AQ7-ARIN
You too, huh? On Tue, 2008-11-18 at 10:05 -1000, Antonio Querubin wrote:
On Tue, 18 Nov 2008, Christopher Morrow wrote:
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either.
vzb's v6 table is far from complete :( which is pretty painful.
That's not all that's broken at vzb. I've been trying to get them to troubleshoot/fix a possible PMTU problem for weeks now. Everytime I try turning up our tunnel with them we lose http connectivity to various web sites (you can still ping/traceroute the same sites) one of which is isc.org.
Antonio Querubin whois: AQ7-ARIN
GRE. The problem we have (I think) is that the tunnel goes to something other than the direct router we have the DS3 on. The tunnel goes: vzb->ds3 router->ethernet->another router We aren't able to do more than a 1500 byte MTU, so when they send packets larger than 1380 or so, the packets never make it to my end. They get an IPv4 packet too large, and their router doesn't do anything to either lower the MTU of the tunnel (they have changed settings on their side but evidently not the right ones, because it's not changed anything at all) or translate that to an IPv6 packet too big somehow, so the packet just disappears into thin air. -Paul On Tue, 2008-11-18 at 13:48 -1000, Antonio Querubin wrote:
On Tue, 18 Nov 2008, Paul Timmins wrote:
You too, huh?
Is your IPv6 tunnel with vzb using GRE or 6-in-4 encapsulation?
Antonio Querubin whois: AQ7-ARIN
On Tue, Nov 18, 2008 at 12:26 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog@daork.net> wrote:
I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with
traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working...
oh hey! this is fixed now :) (Thanks anonymous 701 engineer in my AIM window!!)
traceroute6 to ipv6.google.com from inside 701, oh... not working either.
Oh, this is also fixed, I get there from virginia -> frankfurt -> 12702 -> someone -> ipv6.google.com! All in .. 225ms or so.
vzb's v6 table is far from complete :( which is pretty painful.
the current table seen on the v6 routeviews box (routeviews6 perhaps?) is: 1495 routes GRH is too slow to get me an answer on what it thinks the v6 table size should be :( Geoff says though: 1627 routes (http://bgp.potaroo.net/v6/as2.0/index.html) -chris
Christopher Morrow wrote:
GRH is too slow to get me an answer on what it thinks the v6 table size should be :( Geoff says though: 1627 routes (http://bgp.potaroo.net/v6/as2.0/index.html)
route-views6 is another good place to look. 1481 is the max seen there. Perhaps there are some internal/customer routes in the feed Geoff is using? route-views6.routeviews.org> sh bgp sum (output snipped for brevity) - Kevin
Robert.E.VanOrmer@frb.gov wrote:
Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification.
Let them signup to GRH (http://www.sixxs.net/tools/grh/) then it will be very easy to see which chunks of the IPv6 routing table they are not seeing. A /48 is perfectly fine. Greets, Jeroen
On Mon, Nov 17, 2008 at 04:46:08PM -0600, Robert.E.VanOrmer@frb.gov wrote:
ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32.
i can verify this. Verizon refused to route $employer's /44. any complaints were met with "just because ARIN gives you space doesn't mean we have to route it". -- bill
participants (27)
-
Antonio Querubin -
bill fumerola -
Christopher Morrow -
Florian Weimer -
Frank Habicht -
Geoff Huston -
Jack Bates -
Jeroen Massar -
Joe Abley -
Joe Maimon -
Joel Jaeggli -
Kevin Loch -
Kevin Oberman -
Leo Bicknell -
Mark Andrews -
Mark Tinka -
Michael Sinatra -
Mohacsi Janos -
Nathan Ward -
Nick Hilliard -
Niels Bakker -
Owen DeLong -
Paul Timmins -
Pekka Savola -
Perry Lorier -
Robert.E.VanOrmer＠frb.gov -
Tony Hain