What is the smallest IPv6 advertisement that organizations are going to honour- are we still looking at a minimum of a /48?
-Don
Anything more specific than /32 is going to be filtered at some portion of the ISPs whether for the good or bad. There are some subsets of the v6 address space that have a higher chance of /48 working (for some definition of 'working') than other parts of the address space, though.
perhaps you might better phrase this as; " Anything more specific
than a /3 is going to be filtered at some portion of the ISPS whether
for the good or bad."
just because you have a prefix of (any) size, does not assure
that everyone will route it.
--bill
Anything more specific than /32 is going to be filtered at some portion of the ISPs whether for the good or bad. There are some subsets of the v6 address space that have a higher chance of /48 working (for some definition of 'working') than other parts of the address space, though.
More specific advertisements always stand a chance of being blocked. I was more interested in whether or not people know of places where they are actively being blocked and why.
That said- ARIN is handing out /48's- should we be blocking validly assigned networks?
-Don
your network might have to to protect it's valuable routing slots. There
are places in the v4 world where /24's are not carried either. So, as Bill
said just cause you get an allocation doesn't mean you can assure
routability of it everywhere.
That said- ARIN is handing out /48's- should we be blocking validly
assigned networks?your network might have to to protect it's valuable routing slots. There
are places in the v4 world where /24's are not carried either. So, as Bill
said just cause you get an allocation doesn't mean you can assure
routability of it everywhere.
I understand the problems but I think there are clear cut cases where /48's make sense- a large scale anycast DNS provider would seem to be a good candidate for a /48 and I would hope it would get routed. Then again that might be the only sensible reason...
-Don
vixie had a fun discussion about anycast and dns... something about him
being sad/sorry about making everyone have to carry a /24 for f-root
everywhere. I think there is a list of 'golden prefixes' or something,
normally this is where Jeroen Masseur jumps in with GRH data and
pointers.
-Chris
vixie had a fun discussion about anycast and dns... something about him
being sad/sorry about making everyone have to carry a /24 for f-root
everywhere.
Whether it's a /24 for f-root or a /20 doesn't really make a difference- it's a routing table entry either way- and why waste addresses.
I think there are a few services where these sorts of exceptions make sense and f-root is certainly one of them.
-Don
f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question.
wfms
Chris L. Morrow wrote:
[..]
vixie had a fun discussion about anycast and dns... something about him
being sad/sorry about making everyone have to carry a /24 for f-root
everywhere. I think there is a list of 'golden prefixes' or something,
normally this is where Jeroen Massar jumps in with GRH data and
pointers.
*see cue* 
3 years ago I did a presentation about that, see
http://www.sixxs.net/presentations/ and then "IPv6 Golden Networks"
for various formats, it is more or less still correct actually, but
some things might have changed.
The "best" way IMHO to figure out what prefixes you should be carrying
and what you are missing out on is to make sure you at least receive
all the allocated blocks.
The lucky folks who are providing a BGP feed to GRH can simply do that
by checking that here: http://www.sixxs.net/tools/grh/dfp/
Everybody else can of course either signup or do it manually.
Every prefix in DFP shows how well connected they are at least per
BGP, and we assume that reachability by BGP means that you can shove
packets over a link. Of course this does not show if the actual link
works vice-versa, or if it is a dsl link in the middle or not 
Should I make an explicit "Golden IPv6 Networks" list available again?
For IPv4 that was moreover done for dampening reasons, I don't know if
that is still needed. In effect any Golden network is more the network
that is most needed by your customers anyway, as such, the full list
is more accurate.
As for folks wanting "IPv6 Google", http://www.google.com.sixxs.org
and then you even get the Dutch version, which is quite liberal
Any <site>.sixxs.org or <sixxs>.ipv6.sixxs.org allos you to access
that <site> over IPv6. Using <sixxs>.ipv4.sixxs.org one can access
IPv6 sites when on IPv4 (which I used for some time when I didn't have
IPv6 connectivity at work due to firewalls which didn't work, but now
they do :). Of course see http://ipv6gate.sixxs.net for more details.
Greets,
Jeroen
In lieu of missing protections for route hijacking there are arguments
to be made for announcing more specifics. As will there be arguments
over where that line should be drawn and who gets to draw it.
John
I once suggested that due to the odd nature of the root name server addresses in the DNS protocol (namely, that they must be hardwired into every caching resolver out there and thus, are somewhat difficult to change), the IETF/IAB should designate a bunch of /32s as "root server addresses" as DNS protocol parameters. ISPs could then explicitly permit those /32s.
However, the folks I mentioned this to (some root server operators) felt this would be inappropriate.
Rgds,
-drc
> I understand the problems but I think there are clear cut cases where
> /48's make sense- a large scale anycast DNS provider would seem to be a
> good candidate for a /48 and I would hope it would get routed. Then
> again that might be the only sensible reason...f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill
pointed-out, another question.
<http://www.arin.net/reference/micro_allocations.html> explains what's going
on with that /48. <http://www.root-servers.org/> shows some other /48's. if
the RIR community wants "critical infrastructure" to use a /48, then f-root's
operator will comply. if the RIR community changes its mind, then f-root's
operator will comply with that, too.
Ironically, AS25689 (that's me) does peer with the local f-root via IPv6, but SIXXS claims I don't see it.
wfms
f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question.
One of the root servers not being available everywhere seems like a pretty lousy idea
On another note- are there any folks on the list who haven't at least started testing v6- either in a lab or on their home network? Is there a particular reason why?
Does anyone have any horror stories about deploying v6? (Aside from problems with tunnels resulting from A and AAAA records for the same host). With rare exceptions every transition I've read about has been pretty painless.
There seems to be so much resistance to v6 and a lot of it seems to be misunderstanding or misinformation regarding the complexity of the changes.
-Don
Should've clarified: this was in the context of IPv4...
To be honest, I'm not sure what the appropriate equivalent would be in IPv6 (/128 or /64? Arguments can be made for both I suppose).
Rgds,
-drc
Does anyone have any horror stories about deploying v6?
not horror, just had to back off.
small site. so public servers provide multiple and diverse services.
if a hostname has a v6 address, then all services must be v6 capable
because clients do not retry the A record.
and, as someone pointed out earlier, hostname hacks do not work; a
referring link can not choose to yield v6.foo as opposed to foo
depending on the abilities of the link follower.
when i have copious spare time, i will try to sort services by v6
abilities and have another go. but spare time is like spare money these
days, sigh.
randy
I found that my bank had nameservers that did not work
properly when asked for the AAAA record as well as the A record. A phone
call to their whois contact data resolved it!
I believe they had to turn on some ipv6 compatability mode even
though they were not doing ipv6 themselves. I suspect some folks are still
using older nameserver software that has this defect. But the majority of
websites these days work properly as the Mozilla, Safari and other browser
engines have been asking about AAAA for years now and i've not seen anyone
broken in years now. I'm sure someone is broken, but nobody I've noticed.
- jared
William F. Maton Sotomayor wrote:
f-root does this on the IPv6 side: 2001:500::/48
Whether that's available everywhere on IPv6 networks, is as Bill
pointed-out, another question.Ironically, AS25689 (that's me) does peer with the local f-root via
IPv6, but SIXXS claims I don't see it.
It doesn't claim any such thing. The "ASNs that do have the prefix"
are the ASNs that are found in the paths for the prefix, as such we
can deduce that these ASNs see that prefix, otherwise they would not
carry them.
Then there is a list of GRH participants, these are sites we know that
exist and should have it.
Thirdly there is a list of ASNs that we see somewhere in the BGP tree.
These latter ones are guessed to not have it as they don't provide a
feed, we don't know for sure, they might and they might not. Sign up
and provide a feed and you will know.
Note that this all stated below the headers too
Greets,
Jeroen
When I do IPv6 trainings, I always clearly state that it is, in principle,
same secure as IPv4: IPsec is the same.
However, you can *always* turn on IPsec with IPv6, which is not always true
for IPv4 (NATs, no end-to-end, etc.).
Also, port scanning is not "so simple", and while in IPv6 a /24 can be
scanned in 5 minutes, a /64 takes 5.3 billion years, and of course, usually
you will have a /48.
So at the time being, it can be considered a bit more difficult to do a
brute force DoS. Of course, attackers will try some other means, that's why
I recommend not numbering the hosts manually in a consecutive way. One
possible choice is to use autoconfiguration the *first* time you power-on a
server, then manually configuring the autoconfigured address and using that
one for the AAAA. This way, the possibility of consecutive addresses is very
low, but at the same time if the interface get broken, you don't need to
update the AAAA.
Regards,
Jordi