Re: European ISP enables IPv6 for all?

> Date: Tue, 18 Dec 2007 11:30:55 -0500
> From: Jared Mauch <jaredpuck.nether.net>
> Sender: owner-nanogmerit.edu
> 
> 
> On Tue, Dec 18, 2007 at 12:06:48PM +0100, Florian
Weimer wrote:
> > 
> > * Jeroen Massar:
> > 
> > > For a list of ISP's doing IPv6 check:
> > > htt
p://www.sixxs.net/faq/connectivity/?faq=native
> > 
> > Does PPPv6 still work on the T-DSL platform? 8-/
> > 
> > The list would be more convincing if it contained
links to product
> > pages.
> 
> 	You likely want to look at this page:
> 
> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit

> 
> 	This is the page that has those that are doing native
> that are reasonably major service providers.

Note that sixxs only deals with commercial providers. Many
(most?) of
the major research and education networks around the globe
have done
IPv6 in production for years. That includes ESnet, DREN,
NREN and
Internet2 in the US, CAnet in Canada, Geant/Dante in Europe
and a number
of national networks in Asia.

At least ESnet has offered IPv6 as a production service for
several
years including DNS service. If you check the headers, you
should see
that this message started out via IPv6 and, if your mail
host is IPv6
reachable, took IPv6 for the entire path.

That said, while we provide IPv6 services, we see minimal
traffic and
have found that IPv6 is, at best, poorly supported by most
vendors
(excluding host OS vendors). Most hosts support IPv6 fairly
well, but
switching and routing equipment lacks many features for IPv6
that are
present for IPv4 and system management and security products
tend to be
even worse. E.g. try SNMP access to your routers by IPv6 and
you might find a
few problems, depending on the vendor...and don't expect
much help from
the vendor.

If you see IPv6 as a solution to the exhaustion of IPv4
space, take a
look at http://www.civ
il-tongue.net/clusterf/. It may help at some
point, but many of us see no clear way to get from here to
there without
massive growth in both the RIB and the FIB in the process.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley
Lab)
E-mail: obermanes.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3
987B 3751

On Tue, 18 Dec 2007, Kevin Oberman wrote:

> If you see IPv6 as a solution to the exhaustion of IPv4
space, take a
> look at http://www.civ
il-tongue.net/clusterf/. It may help at some
> point, but many of us see no clear way to get from here
to there without
> massive growth in both the RIB and the FIB in the
process.

I am actually more concerned with the CPE problem and how to
make 
autoconfiguration work for end users.

For instance, should we assign /64 to end users and have
them do whatever 
they need (subnet to /80 if they need more than one
network)? We need to 
provision routes in whatever routers connect to customers,
which I guess 
is the FIB/RIB-problem mentioned above?

Is there general agreement that IPv6 requires a router at
the customer 
prem to scale (ISP doesn't want to know what the end user
devices are)?
Also, is it ok to statically assign /64 to end user or
should end user be 
able to switch addresses (some like dynamic IPs because it's
not 
persistant over time and like the "privacy" you
get by changing IP all the 
time).

I haven't been able to find a BCP regarding the end user
equipment and how 
to configure it, does anyone have any pointers?

-- 
Mikael Abrahamsson    email: swmikeswm.pp.se

On Wed, 19 Dec 2007, Mikael Abrahamsson wrote:

>
> On Tue, 18 Dec 2007, Kevin Oberman wrote:
>
>> If you see IPv6 as a solution to the exhaustion of
IPv4 space, take a
>> look at http://www.civ
il-tongue.net/clusterf/. It may help at some
>> point, but many of us see no clear way to get from
here to there without
>> massive growth in both the RIB and the FIB in the
process.
>
> I am actually more concerned with the CPE problem and
how to make 
> autoconfiguration work for end users.
>
> For instance, should we assign /64 to end users and
have them do whatever 
> they need (subnet to /80 if they need more than one
network)? We need to 
> provision routes in whatever routers connect to
customers, which I guess is 
> the FIB/RIB-problem mentioned above?
>
> Is there general agreement that IPv6 requires a router
at the customer prem 
> to scale (ISP doesn't want to know what the end user
devices are)?
> Also, is it ok to statically assign /64 to end user or
should end user be 
> able to switch addresses (some like dynamic IPs because
it's not persistant 
> over time and like the "privacy" you get by
changing IP all the time).


In my opinion there is two type of users as usually ISP
services are 
marketed:

1. Home user - not really interested in configuration of
their devices - 
they just want Internet (now IPv4, soon IPv4 and IPv6)
connectivity: They 
generaly don't use more than one LAN internally. All their
devices are 
connected either directly to ISP device or to the
home-gateway purchased 
at the cornet. In this case the /64 with autoconfiguration
is the best 
option. User don't have to configure anything (may be
enabling IPv6 on 
their computers).

2. Power users/business users - they can configure their
devices, and they 
want measured and reported SLAs. If they want IPv6 they can
articulate 
their needs: /64, /60, /56, or /48 with prioritisation,
filtering
and other business needs. In this case DHCPv6 prefix
delegation seems to 
be the most flexible solution. Since they can configure
basic things on 
their device. The ISP can help them and negotiate
accordingly...


In my opinion 99% of the users belongs to the home user
category. However 
I think 80% the IPv6 traffic volume will be generated by
power/business 
users.

>
> I haven't been able to find a BCP regarding the end
user equipment and how to 
> configure it, does anyone have any pointers?

There is a draft that starts addressing the CPE problem
available at:
http://tools.ietf.org/html/draft-ietf-v6ops-cp
e-simple-security-00

If you think you can contribute, IETF v6ops welcomes you.

Best Regards,
  		Janos Mohacsi

On 19 dec 2007, at 10:16, Mikael Abrahamsson wrote:

> I am actually more concerned with the CPE problem and
how to make  
> autoconfiguration work for end users.

> For instance, should we assign /64 to end users and
have them do  
> whatever they need (subnet to /80 if they need more
than one network)?

Subnets that aren't /64 don't support autonegotiation so you
can't  
really subnet a /64 in practice. This means that you should
probably  
give your customers something bigger, like a /64, a /56 or
even a /48.  
(Yes, we have enough address space for a /48 per customer.)

The tricky part is provisioning a subnet to a customer.
There is a  
good protocol for that: DHCPv6 prefix delegation. But there
aren't any  
CPEs on the market that support this. (If it wasn't for
Apple's  
Airport Extreme base station and a few somewhat expensive
and hard to  
configure Cisco boxes you could argue that there aren't any
IPv6- 
capable CPEs commercially available in the first place.)

> We need to provision routes in whatever routers connect
to  
> customers, which I guess is the FIB/RIB-problem
mentioned above?

Don't think so. As long as you don't let your customers take
their  
address space with them when they move you can aggregate
customer  
space in your network (you can even waste some address space
for that  
without complaints from ARIN) so in practice your IPv6
routing tables  
will probably be smaller than their IPv4 counterparts.

> Is there general agreement that IPv6 requires a router
at the  
> customer prem to scale (ISP doesn't want to know what
the end user  
> devices are)?

The alternative is having your device act as the default
gateway in  
your customer's LAN, which more or less means you need to
have a  
separate subnet/VLAN per customer, which is usually not the
best way  
to go in larger setups. Don't expect to be doing much with
DHCP for  
IPv6, though, most stuff that's out there today doesn't
support it and  
you still need router advertisements because DHCPv6 doesn't
tell you  
your default gateway.

> Also, is it ok to statically assign /64 to end user or
should end  
> user be able to switch addresses (some like dynamic IPs
because it's  
> not persistant over time and like the
"privacy" you get by changing  
> IP all the time).

Customers can already randomize the lower 64 bits of their
address so  
there is some level of privacy. In a prefix delegation
system I would  
probably make things such that customers get the same
addresses for  
some time (a few months) but I get to change their prefix
if/when I  
want to.

> I haven't been able to find a BCP regarding the end
user equipment  
> and how to configure it, does anyone have any
pointers?

Unfortunately, there is no industry-wide consensus on how
CPEs and ISP  
equipment should interact for IPv6, so it's probably not
possible at  
this point in time to make a CPE that will completely
autoconfigure  
unless you stick to 6to4 tunneling which gets the job done
but is less  
than optimal because it needs public gateways.

On Wed, 19 Dec 2007, Iljitsch van Beijnum wrote:

> customers something bigger, like a /64, a /56 or even a
/48. (Yes, we have 
> enough address space for a /48 per customer.)

The good part about using /48 is that it gives customers an
even : boundry 
for their space. Apart from that, I think /56 is a better
idea (or perhaps 
even a /60). Good point there about autoconfiguration,
subnetting using 
less than /64 is probably a bad idea.

So, out of our /32, if we assign each customer a /48 we can
only support 
65k customers. So in order to support millions of customers,
we need a new 
allocation and I would really like for each new subnet
allocated to be 
very much larger so we in the forseeable future don't need
to get a newer 
one. So for larger ISPs with millions of customers, next
step after /32 
should be /20 (or in that neighborhood). Does RIPE/ARIN
policy conform to 
this, so we don't end up with ISPs themselves having tens of
aggregates 
(we don't need to drive the default free FIB more than
what's really 
needed).

Other option is to have more restrictive assignments to end
users and 
therefore save on the /32, but that might be bad as well
(long term).

-- 
Mikael Abrahamsson    email: swmikeswm.pp.se

On 19 Dec 2007, at 11:58, Mikael Abrahamsson wrote:
> So, out of our /32, if we assign each customer a /48 we
can only  
> support 65k customers. So in order to support millions
of  
> customers, we need a new allocation and I would really
like for  
> each new subnet allocated to be very much larger so we
in the  
> forseeable future don't need to get a newer one. So for
larger ISPs  
> with millions of customers, next step after /32 should
be /20 (or  
> in that neighborhood). Does RIPE/ARIN policy conform to
this, so we  
> don't end up with ISPs themselves having tens of
aggregates (we  
> don't need to drive the default free FIB more than
what's really  
> needed).

 From the RIPE perspective, there are seven
"empty" /32s between my / 
32 and the next allocation.

I imagine this is fully intentional, and allows the NCC to
grow my v6  
address pool, without growing my footprint in the v6 routing
table.

Andy

Changing subject for these replies which will definitely be
a bit on the
quite mean side... no offense but start reading for once.
Next to that
there are also LIR courses which cover all of this.

(see other mail for /56 for end-user-sites, /48 for
end-business-sites)

Mikael Abrahamsson wrote:
[..]> So, out of our /32, if we assign each customer a
/48 we can only
> support 65k customers.

Can I read from this that you never actually read any of the
$RIR policy
documentation about getting IPv6 address space even though
you did
request a /32 before, clearly without thinking about it?

> So in order to support millions of customers, we need
a
> new allocation

"new" as in "We already have one, but we
actually didn't really know
what we where requesting, now we need more"

 and I would really like for each new subnet allocated to
> be very much larger so we in the forseeable future
don't need to get a
> newer one. So for larger ISPs with millions of
customers, next step
> after /32 should be /20 (or in that neighborhood). Does
RIPE/ARIN
> policy conform to this, so we don't end up with ISPs
themselves having
> tens of aggregates (we don't need to drive the default
free FIB more
> than what's really needed).

This explains quite a bit why people are looking so weird
when certain
other organizations get a /20 and upward from $RIR.

My suggestion: start reading.

> Other option is to have more restrictive assignments to
end users and
> therefore save on the /32, but that might be bad as
well (long term).

That would be stupid and totally against the idea of IPv6.

Andy Davidson wrote:
[..]
> From the RIPE perspective, there are seven
"empty" /32s between my /32
> and the next allocation.
> 
> I imagine this is fully intentional, and allows the NCC
to grow my v6
> address pool, without growing my footprint in the v6
routing table.

That is exactly what it is for. Then again, if you actually
had
*PLANNED* your address space like you are supposed to when
you make a
request you could have already calculated how much address
space you
really needed and then justify it to the $RIR. In case you
have to go
back to ask the $RIR for more you already made a mistake
while doing the
initial request...

Greets,
 Jeroen

KEVIN OBERMAN WROTE:
[..]
> NOTE THAT SIXXS ONLY DEALS WITH COMMERCIAL PROVIDERS.
MANY (MOST?) OF
> THE MAJOR RESEARCH AND EDUCATION NETWORKS AROUND THE
GLOBE HAVE DONE
> IPV6 IN PRODUCTION FOR YEARS. THAT INCLUDES ESNET,
DREN, NREN AND
> INTERNET2 IN THE US, CANET IN CANADA, GEANT/DANTE IN
EUROPE AND A NUMBER
> OF NATIONAL NETWORKS IN ASIA.

WHICH IS A WELL KNOW FACT AND WHO HAVE QUITE A LIMITED SET
OF END-SITES
WHO CAN ACTUALLY CONNECT TO THEM, THAT IS WHY THESE ARE NOT
LISTED.
SIMILARLY IT DOESN'T LIST HOSTING PROVIDERS EITHER, ENABLING
A COLO TO
DO IPV6 SHOULD BE CHILDS PLAY, GETTING IT TO THE ENDUSER
THOUGH... ;)

> THAT SAID, WHILE WE PROVIDE IPV6 SERVICES

YOU PROVIDE SERVICES AND ACCESS, BUT WHICH PLACES ARE
ACTUALLY ENABLED
TO USE IT? THAT THE NETWORK IS THERE IS ONE THING, THIS IS
THE EASY
PART, LINKING UP THE END-SITES IS THE HARD ONE.

GREETS,
 JEROEN

Mohacsi Janos wrote:
[..]
> In my opinion there is two type of users as usually ISP
services are
> marketed:
> 
> 1. Home user - not really interested in configuration
of their devices -
> they just want Internet (now IPv4, soon IPv4 and IPv6)
connectivity:
> They generaly don't use more than one LAN internally.
All their devices
> are connected either directly to ISP device or to the
home-gateway
> purchased at the cornet. In this case the /64 with
autoconfiguration is
> the best option. User don't have to configure anything
(may be enabling
> IPv6 on their computers).

This would force these places to:
 a) use bridging to get that single /64 onto their network
    thus making firewalling really difficult.
 b) get a 'power users' abo, which would thus make people
have
    to PAY for getting more IP addresses.

ISP's are paying their transits by paying for the
*BANDWIDTH* usage.
So why don't ISP's have a couple of classes (to keep it
simple) which
are like eg:
  10Gb account
  50Gb account
 100Gb account

This would also solve the "Those stupid users are
torrenting" problem,
as they are PAYING for the traffic and other costs that you
actually have.

Don't charge for IP addresses, charge for *BANDWIDTH* usage.
If I have
200 devices on the network which don't do a thing (maybe
they are light
bulbs or it is my fridge) I will do much less traffic than
one single
user who is trying to complete his nature movie collection.

> 2. Power users/business users - they can configure
their devices, and
> they want measured and reported SLAs. If they want IPv6
they can
> articulate their needs: /64, /60, /56, or /48 with
prioritisation,
> filtering
> and other business needs. In this case DHCPv6 prefix
delegation seems to
> be the most flexible solution. Since they can configure
basic things on
> their device. The ISP can help them and negotiate
accordingly...

Scratching the 'power users' concept, as they belong in the
above home
user part, I agree.

Greets,
 Jeroen

On 19 Dec 2007, at 12:24, Jeroen Massar wrote:

> Andy Davidson wrote:
> [..]
>> From the RIPE perspective, there are seven
"empty" /32s between  
>> my /32 and the next allocation.
>> I imagine this is fully intentional, and allows the
NCC to grow my  
>> v6 address pool, without growing my footprint in
the v6 routing  
>> table.
> That is exactly what it is for. Then again, if you
actually had  
> *PLANNED* your address space like you are supposed to
when you make  
> a request you could have already calculated how much
address space  
> you really needed and then justify it to the $RIR. In
case you have  
> to go back to ask the $RIR for more you already made a
mistake  
> while doing the initial request...

With respect, Jeroen, because I did *PLAN* (your emphasis)
our  
organisational requirements, this is precisely the reason
why I think  
it's significant that a lot of space was left unallocated
following  
my allocation.

My RIR only asked me to *PLAN* two years in advance (see
ripe-414  
[footnote 0]), though prudent organisations may plan for
longer.  I  
thought it was significant (and good) to note that they are
allow me  
room to grow sometime after that period.

If you offer the sweeping statement that anyone who ever
needs to go  
back to the RIR for more space has made a 'mistake' with
their  
requirement planning shows you're only thinking in an
incredibly  
short term manner.  Unless, of course, you are only used to
working  
in companies which do not grow. 



---

[0]
#[IPv6 ALLOCATION USAGE PLAN]#
%
% When will you use this address space?
%
%       Subnet       Within     Within   Within
%       size (/nn)   3 months   1 year   2 years   Purpose

subnet:
subnet: