North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Addressing versus Routing (Was: Deploying IPv6 in a datacenter)
- From: Kevin Day
- Date: Thu Dec 22 14:40:30 2005
Ok, I promise this is my last reply to the list about this... This
has gone too far into theoretical and not operational content, and
probably belongs on an IPv6 policy list, so I'll hush. :) I'll
follow up with anyone privately who wants to continue the discussion
On Dec 22, 2005, at 4:56 AM, Jeroen Massar wrote:
Kevin Day wrote:
No, the proposed policy says that if you get a /44 you must
that connectivity through it's single aggregated address assignment."
Get a /48 from your provider? Your provider can only give /48s to
organizations "through its single aggregated address allocation".
Please read the answer from Gert Doering to a question I posted:
This is also why I changed the subject to "Addressing versus Routing".
RIR's provide *Address Space* how the routing happens is up to you.
In IPv6, allocations or
Why? There really won't be a single RIR going to complain to you.
assignments are at /48 and /44, and you must advertise the entire
and ONLY the entire thing.
also *impossible* for them to stop it. See also above.
The only parties that can stop it is your peers as they can filter it.
This is the same as trying to announce a IPv4 /28, if you can persuade
$world to accept it you are done. But most folks filter on /24.
While I really really WISH this is how it worked, my (and others I've
asked) interpretation of what advertising a "single aggregated
address assignment" means that ARIN does intend it to be their policy
that you don't deaggregate at all. I'll email ARIN to see if I can
get an official clarification. However, my opinion is that if they
say "If you want IP addresses from us, you agree to do (whatever)",
you'd better do what they ask. I know they can't technically prevent
us from doing something in BGP, but there's a clause in the ARIN
agreement that you have to sign before getting any space from them
"If ARIN determines that the numbering resources or any other
Services are not being used in compliance with this Agreement, the
Policies, or for purposes for which they are intended, ARIN may: (i)
revoke the numbering resources, (ii) cease providing the Services to
Applicant, or (iii) terminate this Agreement."
So, in my book, if the RIR says I gotta do X, no matter how unfair X
is, I'll do it rather than risk having them revoke my assignment. We
don't want to end up in a situation where everyone is breaking the
This is completely different than IPv4 though. Nothing in the IPv4
policies says anything about what announcements you can make. The "/
24 is the smallest block that you can rely on the world listening to"
policy isn't mandated by assignment policy, and it matches what the
smallest block that you could get (at least, at one point, I know you
can get smaller now, but it's well known that nobody will hear it).
IPv6 is new in that it does make part of the assignment and
allocation policy what you do with it in BGP space, and that's what
concerns me. If a new /16 were allocated specifically for /44 sized
end-user blocks, and the policies stated that /44's can't be
deaggregated, you know there are a good number of providers who are
going to filter everything smaller than a /44 inside that /16,
"because the policy says you can't do that anyway".
In IPv4, filtering on a /24 works because everything is assigned in
multiples of /24's, and nearly everyone who would need to deaggregate
qualifies for multiple /24 sized pieces. In IPv6, unless you're
getting a /32, you're being allocated or assigned a block that can't
be split up.
Yes, but that dramatically increases my expenses(I'm having to haul
traffic around myself, paying for transit on it twice), and causes
really sub-optimal routing. If someone else is a customer of ISP A,
they're in Los Angeles and trying to reach my LA POP, ISP A is going
to take their traffic all the way to New York, only for me to VPN it
back to LA.
In New York, I buy transit from ISP A and ISP B.
Correct. One of the few solutions you can do is setup connectivity
In Los Angeles, I buy transit from ISP C and ISP D. ISP A and B don't
sell service in LA.
I can announce New York and LA's /48 to each provider there, but
are going to be networks out there who filter out /48's, so I need to
advertise the /44 somewhere. Where do I advertise it?
If I advertise the /44 in both and a single /48 only in NY, C and
going to see our NY advertisement through whoever they're buying
from. If their providers filter out my /48's, C and D won't see
at all, so they'll send all my traffic for my NY office to LA, that I
won't be able to route anywhere.
or so) of your own between them. This is a routing issue. You can also
try to persuade $world to accept it.
I realize IPv6 is really big. Vastly hugely mindbogglingly big, and
all that. It's so big that we don't need to worry about wasting
space, which is really great in theory. But if we start assigning /
48's to every 1U box out there, regardless of need, we're going to
burn through /32's faster than anyone is predicting.
In current IPv4 practice, it's common for
Why is that overkill? The person getting the /48 is an endsite and he
hosting companies to dump racks and racks of servers into a /22 or
/24-ish sized block. I could see assigning a /48 to "colo
giving each one a /64 if they needed it, but a /48 each is
a 1U box.
makes a VPN tunnel setup for all his employees from that box
doing it from the 8mbit office they have.
I'm not saying a 1U box can't have a /48, I'm saying it probably
doesn't need to have one automatically assigned in a hosting company
environment. Assigning every 1U box you have a /48 is a great way to
meet the /32 requirements, but I kinda question the necessity.
Personally, if I were doing colo or dedicated IPv6 hosting, unless
the customer specified a need otherwise, groups of servers would
share a /64. Customers could request a /64 of their own, or if they
could demonstrate a need, get a /48.
In my defense, I wasn't even aware of the deaggregation terms in the
IPv6 policy until after we started looking at IPv6 ourselves in a
serious way. I agree that just complaining doesn't help, but I'm not
sure I'm the right guy to do anything about it at this stage. :)
(Funnily I see people complain about the current policy and limits
"have been laid upon" but they never seem to come forward with an
proposal which satisfies their needs, complaining doesn't help,