Hoping to not start a war...
We (a multi-homed end-user site) are finally getting IPv6-enabled Internet
connectivity from one of our ISPs. In conversations regarding our BGP
config, the ISP has balked at allowing us to advertise our ARIN-assigned
/44, saying things like, "do you know how many addresses that is!!??"
Am I way off base in thinking this network size is not out of the norm? I
know it's a lot of addresses (19 octillion-something?), but that
assignment was based on the same criteria that got us a /22 in v4 space.
Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting
a /22 in v4?
Thanks,
John
Hoping to not start a war...
We (a multi-homed end-user site) are finally getting IPv6-enabled Internet
connectivity from one of our ISPs. In conversations regarding our BGP
config, the ISP has balked at allowing us to advertise our ARIN-assigned
/44, saying things like, "do you know how many addresses that is!!??"
Sounds like the ISP in question is in need of some serious IPv6 clue. The number of hosts means nothing, in terms of BGP advertisements. In fact, fewer announcements is better. De-aggregation bloats the global routing table.
Most carriers I've seen will accept IPv6 announcements as small as a /48.
If your /44 was assigned by your RIR, and it's documented in their whois/rwhois/route registry, your ISP really doesn't have a leg to stand on, regarding not accepting your announcement.
Am I way off base in thinking this network size is not out of the norm? I
know it's a lot of addresses (19 octillion-something?), but that
assignment was based on the same criteria that got us a /22 in v4 space.
Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting
a /22 in v4?
The largest IPv6 prefix I saw in the global Internet routing table the last time I looked (a few months ago) that wasn't for a special purpose was a /19.... ~33 million times larger than a /44.
Your ISP should have more constructive things to do than hassling a customer about announcing a /44.
jms
No, it's not mis-sized. And no, you should advertise it all.
I would advertise the /44 without reservation.
Stuart Sheldon
ACT USA
AS22937
Hoping to not start a war...
We (a multi-homed end-user site) are finally getting IPv6-enabled Internet
connectivity from one of our ISPs. In conversations regarding our BGP
config, the ISP has balked at allowing us to advertise our ARIN-assigned
/44, saying things like, "do you know how many addresses that is!!??"
Am I way off base in thinking this network size is not out of the norm? I
know it's a lot of addresses (19 octillion-something?), but that
assignment was based on the same criteria that got us a /22 in v4 space.
Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting
a /22 in v4?
Thanks,
John
--
John York
Information Technology | Network Administrator
Phone:
615-399-7000 x:333
Griffin Technology
2030 Lindell Avenue Nashville, TN 37203 USA
- --
My pockets are empty though my wife has sent me to the store for some
cigarettes and bread... I started walkin there, got as far as the
square, then the smell of beer went to my head... The thing about
beer, it can make a man hear, voices from days long since past, and
with every third drink, it will make you think that your youth will
always last...
-- BR549 - "Lifetime to Prove Lyrics"
Pretty strong reaction for a single prefix.
Now if you said you wanted to advertise all your /64¹s that would be a
different conversation.
Yeah, we're good in WHOIS, we're trying to announce only the aggregate, I
think we have all our ducks in a row.
Thanks to all who replied on- and off-list with your input. I'll go back
to the ISP with the info from you guys and girls, and hopefully they'll
listen to reason.
John
Hoping to not start a war...
We (a multi-homed end-user site) are finally getting IPv6-enabled Internet
connectivity from one of our ISPs. In conversations regarding our BGP
config, the ISP has balked at allowing us to advertise our ARIN-assigned
/44, saying things like, "do you know how many addresses that is!!??"
Your ISP needs a IPv6 clue bat to be applied. Your ISP needs to
learn that a /44 is 16 sites. It is also the next nibble boundry
above a /48. The ISP shouldn't care about the number of addresses.
You have justified your allocation based on the fact you are
multi-homed and presumably the number of sites.
The ISP appears to be wildly off base.
Am I way off base in thinking this network size is not out of the norm? I
know it's a lot of addresses (19 octillion-something?), but that
assignment was based on the same criteria that got us a /22 in v4 space.
Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting
a /22 in v4?
Address allocation in IPv6 is, or should be, number-of-sites based
in IPv6 for end customers with a site gettting a /48. The exception
is when a site needs more that 2^16 /64 subnets at a site which
needs justification. For ISPs it is number-of-customer-sites (1
home == 1 site == 1 customer, commercial customers may have more
than one site and need a bigger allocation) based with tuning for
number-of-pops along with the customer allocation size (a /48 per
customer site is reasonable though some ISPs do /56).
IPv4 prefix size should have no bearing on the size of the IPv6
prefix for end customers. In IPv4 you count hosts. In IPv6 you
count sites. This is as different as comparing apples and oranges.
Just because you need a /22 in IPv4 doesn't mean you need a /44 in
IPv6. You should be requesting address space based on the number
of sites one has.
Mark
It may also help to point out to them that under ARIN policy, if you need more than a single /48, you will get at least a /44. ARIN does not issue non-nibble-aligned blocks any more.
You can get /12, /16, /20, /24, /28, /32, /36, /40, /44, /48, but you can't get a /45, /46, or /47.
IMHO this is a good thing as it simplifies administration, DNS, and likely RPKI. It also reduces table bloat, and human factors related events. (At 3 am it turns out most people are bad at bit math).
If your ISP would like, I am available to provide ipv6 training or consulting.
Owen