Re: ISP customer assignments

[Mark Andrews]

In message , "Ricky Beam" writes:
> On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart   
> wrote:
> > ... If you've got a VPN tunnel device, too often the remote
> > end will want to contact you at some numerical IPv4 address and isn't
> > smart enough to query DNS to get it.
> 
> As I was told by Cisco, that's a security "feature".  Fixed VPN endpoints  
> are supposed to be *fixed* endpoints.  Yes, it is a pain when an address  
> changes, for whatever reason.  But relying on DNS to eventually get the  
> endpoint(s) right is an even bigger mess... how often is the name<->IP  
> updated?

It should be automatically updated by the end point.  We do have
the technology to do that.

> how often do the various DNS servers revalidate those records?  

If you are talking about caching servers then they will honour the
TTL in the records.

> how often do the VPN devices revalidate the names?

At startup.  A well designed VPN protocol will support end point
address mobility.

> what happens when the dns changes while the vpn is still up?

This should be transparent to everything other than the vpn end
points.

> I'll stick with entering IP addresses.
> 
> --Ricky
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP customer assignments

[Ricky Beam]

On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart   
wrote:

... If you've got a VPN tunnel device, too often the remote
end will want to contact you at some numerical IPv4 address and isn't
smart enough to query DNS to get it.


As I was told by Cisco, that's a security "feature".  Fixed VPN endpoints  
are supposed to be *fixed* endpoints.  Yes, it is a pain when an address  
changes, for whatever reason.  But relying on DNS to eventually get the  
endpoint(s) right is an even bigger mess... how often is the name<->IP  
updated? how often do the various DNS servers revalidate those records?  
how often do the VPN devices revalidate the names? what happens when the  
dns changes while the vpn is still up?


I'll stick with entering IP addresses.

--Ricky

Re: ISP customer assignments

[Tim Chown]

On Tue, Oct 20, 2009 at 10:15:39PM -0400, Roland Dobbins wrote:
> 
> On Oct 20, 2009, at 8:41 PM, Karl Auer wrote:
> 
> >In practice, changing stuff, especially globally, is not as simple  
> >as that.
> 
> From :
> 
> 'Some took it on themselves to convince the authors that the concept  
> of network renumbering as a normal or frequent procedure is daft.'

We tried Fred's procedure some 4 years ago within 6NET:
http://www.6net.org/publications/deliverables/D3.6.2.pdf

The 'prefix schizo' actually worked out quite well.  The routing changes
and multi-refix links generally behaved as expected.   Address selection
did its thing.   The basics worked as advertised.

The complexity is of course not in the routing and hosts, it's as pointed 
out in the firewalls and similar devices (yours and more importantly other 
people's) for which new capabilities of IPv6 can't help.

We captured some of these thoughts at the time in
http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout-05

and since then Brian Carpenter has produced a much more up to date and
rounded set of thoughts in
http://tools.ietf.org/html/draft-carpenter-renum-needs-work-03

We're far from a magic button press.   In smaller networks RFC4192
is workable, but the larger and more complex the network/site, there's
still so many open issues that it's completely understandable the
people will want PI.

-- 
Tim

Re: ISP customer assignments

[Roland Dobbins]

On Oct 20, 2009, at 10:29 PM, Mark Andrews wrote:


Remember there are lots of machines that renumber themselves several
times a day as they move between work and home


The problem isn't largely with the endpoints - it's with all the other  
devices/policies/etc. which overload the EID with inappropriate  
significance which tend to cause most of the problems.


---
Roland Dobbins  // 

Sorry, sometimes I mistake your existential crises for technical
insights.

-- xkcd #625

Re: ISP customer assignments

[Mark Andrews]

In message <1069dfd4-87a3-4e38-aebc-43c05c16d...@arbor.net>, Roland Dobbins wri
tes:
> On Oct 20, 2009, at 8:41 PM, Karl Auer wrote:
> 
> > In practice, changing stuff, especially globally, is not as simple  
> > as that.
> 
>  From :
> 
> 'Some took it on themselves to convince the authors that the concept  
> of network renumbering as a normal or frequent procedure is daft.'

There is a difference between renumbering every minute and renumber
when required to optimise something else.  We shouldn't be afraid
to renumber.  It should be something all vendors support.  It should
be as automated as possible.  If there is a manual step you should
be asking yourself "does this need to be done by hand".

Remember there are lots of machines that renumber themselves several
times a day as they move between work and home.  All machines should
be in a position to renumber themselves as easily as we renumber a
laptop.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP customer assignments

[Roland Dobbins]

On Oct 20, 2009, at 8:41 PM, Karl Auer wrote:

In practice, changing stuff, especially globally, is not as simple  
as that.


From :

'Some took it on themselves to convince the authors that the concept  
of network renumbering as a normal or frequent procedure is daft.'


---
Roland Dobbins  // 

Sorry, sometimes I mistake your existential crises for technical
insights.

-- xkcd #625

Re: ISP customer assignments

[Mark Andrews]

In message <1256085698.30246.109.ca...@karl>, Karl Auer writes:
> > There is no need to say at XX:XX on DD/MM/ we will be switching
> > prefixes.  One can be much smarter about how you do it.
> >=20
> > You can just introduce the new prefix.  Add second address to the
> > DNS.  Do your manual fixes.  Remove the old addresses from the DNS.
> > Stop using the old prefix when you are satisfied that there is no
> > traffic over them.
> 
> True in principle. In practice, changing stuff, especially globally, is
> not as simple as that.
> 
> Many (most?) enterprises still have pretty primitive DNS/DHCP
> management. While there are good management systems out there, many of
> the largest are custom made for the enterprise concerned, and are not
> yet up to speed with IPv6. The practical experience is not yet there to
> drive the development of the right features - especially ones as rare as
> a complete renumbering.
> 
> DHCPv6 server software is still pretty early days, too.
> 
> The addressing on infrastructure kit like routers and switches,
> firewalls and IDS boxes and so on is also typically hard coded and
> difficult to change, as are the addresses used in ACLs and firewall
> rules.
> 
> Renumbering means:
> 
> - adding a new  record to the DNS for every existing  record,
> but using a different prefix (plus any other DNS changes needed - like
> giving the servers themselves addresses in the new prefix, and making
> sure they reply from the right address...) Reverse lookups may be an
> issue during the changeover, too.
> 
> - updating DHCP configurations to issue addresses from the new prefixes,
> automatically divided along the same numbering plan
> 
> - setting up reserved DHCP addresses with the same host parts as the old
> reserved addresses but using the new prefix etc
> 
> - adding new addresses to every location where an address is hardcoded -
> such as in router and switch configurations
> 
> - updating ACLs to account for the new addresses (without discarding the
> old rules yet)
> 
> - updating firewall rules and what-have-you to account for the new
> prefix, without discarding the old ones yet
> 
> - waiting the weeks or months until the old prefix may be safely
> discarded. During this time you have a prefix-schizo network.
> 
> - updating firewall rules and what-have-you to remove the old prefix
> 
> - updating ACLs to remove the old addresses
> 
> - removing old addresses from every location where an address is
> hardcoded - such as in router and switch configurations
> 
> - removing now-unused DHCP reservations
> 
> - removing now-unwanted DHCP ranges
> 
> - removing all  records that reference the old prefix
> 
> ... and this is by no means an exhaustive list. Many higher-level
> services will also need updating (twice) - your web server
> configurations, for example. And it gets more complicated if your prefix
> changes length as well. And what if the network was not set up with
> future renumbering in mind? DHCP servers issuing eternal leases, things
> like that.
> 
> So once again the theory is good, but reality intrudes. Renumbering,
> even with the undeniably much better features of IPv6, is still going to
> be a royal pain. Of course, IPv6 may drive improvements in all these
> areas over time, but they're not there yet.
>
> Wouldn't it be cool to have a "renumber router" command that just took
> an old prefix, a new prefix and a number of seconds and did all the
> work?

Well request it from you favorite router vendors.  Router/vpn/firewall
vendors should be forced to renumber annually.  That way they would
have some incentive to make their products usable when a renumber
event occurs.  The same applies to other vendors.

> Regards, K.
> 
> PS: If anyone knows of an IPAM that can do all the above, or even just
> some of the above, please let me know!
> 
> --=20
> ~~~
> Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
> http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)
> 
> GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
> 
> 
> --=-lq/A/spfwZ9P7pLx73k/
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEABECAAYFAkreWLgACgkQSkRqA/Q6fe//UACfcPMTlaufxR4sk8pfJ9d7Uk/W
> rW4AmgNnotHOzM4DnvcT90ow+0kDxMVF
> =aZzD
> -END PGP SIGNATURE-
> 
> --=-lq/A/spfwZ9P7pLx73k/--
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP customer assignments

[Karl Auer]

> There is no need to say at XX:XX on DD/MM/ we will be switching
> prefixes.  One can be much smarter about how you do it.
> 
> You can just introduce the new prefix.  Add second address to the
> DNS.  Do your manual fixes.  Remove the old addresses from the DNS.
> Stop using the old prefix when you are satisfied that there is no
> traffic over them.

True in principle. In practice, changing stuff, especially globally, is
not as simple as that.

Many (most?) enterprises still have pretty primitive DNS/DHCP
management. While there are good management systems out there, many of
the largest are custom made for the enterprise concerned, and are not
yet up to speed with IPv6. The practical experience is not yet there to
drive the development of the right features - especially ones as rare as
a complete renumbering.

DHCPv6 server software is still pretty early days, too.

The addressing on infrastructure kit like routers and switches,
firewalls and IDS boxes and so on is also typically hard coded and
difficult to change, as are the addresses used in ACLs and firewall
rules.

Renumbering means:

- adding a new  record to the DNS for every existing  record,
but using a different prefix (plus any other DNS changes needed - like
giving the servers themselves addresses in the new prefix, and making
sure they reply from the right address...) Reverse lookups may be an
issue during the changeover, too.

- updating DHCP configurations to issue addresses from the new prefixes,
automatically divided along the same numbering plan

- setting up reserved DHCP addresses with the same host parts as the old
reserved addresses but using the new prefix etc

- adding new addresses to every location where an address is hardcoded -
such as in router and switch configurations

- updating ACLs to account for the new addresses (without discarding the
old rules yet)

- updating firewall rules and what-have-you to account for the new
prefix, without discarding the old ones yet

- waiting the weeks or months until the old prefix may be safely
discarded. During this time you have a prefix-schizo network.

- updating firewall rules and what-have-you to remove the old prefix

- updating ACLs to remove the old addresses

- removing old addresses from every location where an address is
hardcoded - such as in router and switch configurations

- removing now-unused DHCP reservations

- removing now-unwanted DHCP ranges

- removing all  records that reference the old prefix

... and this is by no means an exhaustive list. Many higher-level
services will also need updating (twice) - your web server
configurations, for example. And it gets more complicated if your prefix
changes length as well. And what if the network was not set up with
future renumbering in mind? DHCP servers issuing eternal leases, things
like that.

So once again the theory is good, but reality intrudes. Renumbering,
even with the undeniably much better features of IPv6, is still going to
be a royal pain. Of course, IPv6 may drive improvements in all these
areas over time, but they're not there yet.

Wouldn't it be cool to have a "renumber router" command that just took
an old prefix, a new prefix and a number of seconds and did all the
work?

Regards, K.

PS: If anyone knows of an IPAM that can do all the above, or even just
some of the above, please let me know!

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: ISP customer assignments

[Mark Andrews]

In message <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c...@mail.gmail.com>, Bill 
Stewart writes:
> On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward  wrote:
> > On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
> >> plus want the ability to take their address
> >> space with them when they change ISPs (because there are too many
> >> devices and applications that insist on having hard-coded IP addresses
> >> instead of using DNS, and because DNS tends to get cached more often
> >> than you'd sometimes like.
> >
> > That's why we have Unique Local Addresses.
> 
> This is the opposite problem - ULAs are for internal devices, and what
> businesses often want is globally routable non-provider-owned public
> addresses.  If you've got a VPN tunnel device, too often the remote
> end will want to contact you at some numerical IPv4 address and isn't
> smart enough to query DNS to get it.

Which just means we should be fixing the VPN box.
 
> And even though most enterprises these days only use registered
> addresses outside the firewall and not inside the firewall, it's still
> a pain to have to renumber everything and wait for everybody's DNS
> caches to expire, so if you're using Provider-independent IP
> addresses, it's much easier to tell your ISP "Sorry, ISP A, I've got a
> better price from ISP B and I'll move all my stuff if you don't beat
> their price."  (Of course, customers like that are often telling ISP B
> "You'll have to be X% cheaper/faster/somethinger than ISP A or I'll
> just stay where I am" and telling ISP C "My main choices are ISP A and
> ISP B but I'd take a lowball quote very seriously...")

Renumbering in IPv6 is not the same as renumbering in IPv4.   IPv6
is designed to support multiple prefixes on the one interface.
There is actually enough address space to support doing this and
allow renumber events to take weeks or months if needed.

There is no need to say at XX:XX on DD/MM/ we will be switching
prefixes.  One can be much smarter about how you do it.

You can just introduce the new prefix.  Add second address to the
DNS.  Do your manual fixes.  Remove the old addresses from the DNS.
Stop using the old prefix when you are satisfied that there is no
traffic over them.
 
> -- 
> 
>  Thanks; Bill
> 
> Note that this isn't my regular email account - It's still experimental so 
> far.
> And Google probably logs and indexes everything you send it.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP customer assignments

[Bill Stewart]

On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward  wrote:
> On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
>> plus want the ability to take their address
>> space with them when they change ISPs (because there are too many
>> devices and applications that insist on having hard-coded IP addresses
>> instead of using DNS, and because DNS tends to get cached more often
>> than you'd sometimes like.
>
> That's why we have Unique Local Addresses.

This is the opposite problem - ULAs are for internal devices, and what
businesses often want is globally routable non-provider-owned public
addresses.  If you've got a VPN tunnel device, too often the remote
end will want to contact you at some numerical IPv4 address and isn't
smart enough to query DNS to get it.

And even though most enterprises these days only use registered
addresses outside the firewall and not inside the firewall, it's still
a pain to have to renumber everything and wait for everybody's DNS
caches to expire, so if you're using Provider-independent IP
addresses, it's much easier to tell your ISP "Sorry, ISP A, I've got a
better price from ISP B and I'll move all my stuff if you don't beat
their price."  (Of course, customers like that are often telling ISP B
"You'll have to be X% cheaper/faster/somethinger than ISP A or I'll
just stay where I am" and telling ISP C "My main choices are ISP A and
ISP B but I'd take a lowball quote very seriously...")


-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

Re: ISP customer assignments

[Nathan Ward]

On 20/10/2009, at 3:10 PM, bmann...@vacation.karoshi.com wrote:


On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote:

On 20/10/2009, at 3:02 PM, Bill Stewart wrote:


plus want the ability to take their address
space with them when they change ISPs (because there are too many
devices and applications that insist on having hard-coded IP  
addresses

instead of using DNS, and because DNS tends to get cached more often
than you'd sometimes like.


That's why we have Unique Local Addresses.



but Nathan,  they are only statistically unique.


Sure, but I don't think that changes my point.

Also if you want to increase your chances of uniqueness (which are  
already pretty good if you're not using subnet 0 or 1 or whatever) you  
can jump on to somewhere on the sixxs site and announce that you're  
using a specific ULA prefix.


--
Nathan Ward

Re: ISP customer assignments

[bmanning]

On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote:
> On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
> 
> >plus want the ability to take their address
> >space with them when they change ISPs (because there are too many
> >devices and applications that insist on having hard-coded IP addresses
> >instead of using DNS, and because DNS tends to get cached more often
> >than you'd sometimes like.
> 
> That's why we have Unique Local Addresses.
> 

but Nathan,  they are only statistically unique.

--bill

Re: ISP customer assignments

[Nathan Ward]

On 20/10/2009, at 3:02 PM, Bill Stewart wrote:


plus want the ability to take their address
space with them when they change ISPs (because there are too many
devices and applications that insist on having hard-coded IP addresses
instead of using DNS, and because DNS tends to get cached more often
than you'd sometimes like.


That's why we have Unique Local Addresses.

--
Nathan Ward

Re: ISP customer assignments

[Bill Stewart]

If you've got an addressing system with enough bits that you don't
have to start stealing them, it makes sense to pick some boundary
length between
 our-problem  :  their-problem
128 bits is long enough, and changing protocols is nasty enough, that
it should let you Never Have To Do It Again.

Originally with IPv6, the boundary was a nice round 64 bits, with the
ISP on the network side and MAC48-based autoaddressing on the user
side, with the user side looking suspiciously similar to Novell
Netware and giving ~64K subnets, and this was back before DHCP had
taken over the world and it was expected that all kinds of weird
little toasters would be using IPv6.
But some relatively sensible people proposed using the (ugly) EUI-64
64-bit MAC, because they Never Wanted To Have To Do This Again Either.
 And unfortunately, because it's a good enough idea to be worth
accepting, it pushes the network boundary somewhat to the left,
because it's pretty obvious that an average household may have
multiple devices that want to autoconfigure themselves, so you
probably will end up needing multiple subnets.  And unfortunately,
there's no obviously correct boundary, and no particular reason for
all ISPs to use the same boundary, so there are endless arguments
about it on NANOG and elsewhere.

In general, /48's big enough for most large complex businesses (except
ISPs), and /60's more than big enough for a household and for many
small businesses, but we've got enough bits that it's worth using
octet-aligned addresses, so /56 is the magic number for them, except
at ISPs that simply don't want to bother giving out anything except
/48s.  There may be special cases for assigning /64s to end users,
such as IPv6-equipped cell phones, but that's a matter for specialized
carriers to provide, or for internal network managers at enterprises.
And if you're big enough to get Provider Independent Address Space and
an AS#, you're big enough to have a /48 of your own.

Now, IPv6 was supposed to allow the development of other
indistinguishable-from-magically advanced technology, such as getting
rid of the growth of routing tables by convincing everybody to be
happy with hierarchically assigned provider-aligned address space, and
unfortunately that hasn't matched the needs of businesses, which need
multihoming for reliability (so they'll be non-provider-aligned for at
least n-1 of their ISPs), plus want the ability to take their address
space with them when they change ISPs (because there are too many
devices and applications that insist on having hard-coded IP addresses
instead of using DNS, and because DNS tends to get cached more often
than you'd sometimes like.  So that problem shows no sign of going
away (in spite of shim6..)

Re: ISP customer assignments - and CIDR

[James R. Cutler]

On Oct 16, 2009, at 5:19 PM, Owen DeLong wrote:

I've taught both.  If you try to teach it in Decimal, Hex, or Octal,  
you're right, it's hard

to teach CIDR and easy to teach classful.


It really does not matter the representation as long as you divide  
your Address Pie with a Binary Knife.  Once you understand that --  
1/2, 1/2 of 1/2, 1/2 of 1/2 of 1/2, ... -- then you should understand  
CIDR.  Then, as Owen suggests, deal with the representation. Works for  
IPv4, IPv6, and, probably, IPv8. ;)


Warning, strong opinion follows: One should never have to mention  
Classful addressing except to note that it is archaic, anachronistic,  
and used only by those who remain ignorant by preference.




James R. Cutler
james.cut...@consultant.com

Re: ISP customer assignments

[Owen DeLong]

I've taught both.  If you try to teach it in Decimal, Hex, or Octal,  
you're right, it's hard

to teach CIDR and easy to teach classful.

If you teach it in binary, I have found that not to be an issue.  Once  
you teach it in binary,
it's fairly easy to move on to showing how octal and hex are just  
different representations
of binary. Then you show dotted decimal as a really old-fashioned way  
of representing

groups of 8 bits.

I've had no trouble teaching it this way, even to people who knew  
nothing about technology.


Owen

On Oct 16, 2009, at 1:51 PM, Daniel Golding wrote:



The big problem here is that CIDR is tough to teach, even to  
engineering students. This seems bizarre and counterintuitive, but  
its true. I know this because I've done it. Its really easy to teach  
classful addressing, on the other hand. Other problems include the  
issue that many of the folks teaching have never had to use CIDR in  
real life, textbook age, and, in some cases, lack of mathematical  
preparation and inclination on the part of students.


Scarier: I was teaching graduate students.

- Dan

On Oct 13, 2009, at 7:53 AM, Joe Abley wrote:



On 2009-10-13, at 07:39, Scott Morris wrote:

No idea, I haven't looked at that stuff in a while.   But I would  
assume

so, as it's easier to build a foundation than jumping straight to
something difficult?


I've found RIP to be a reasonable way to teach the concept of a  
routing protocol, since the protocol is very simple and you can  
always close with "don't ever use this".


But teaching classful routing and addressing is just moronic. It's  
a foundation that nothing is built on any more, and makes no sense  
to teach outside of a history class.



Or did you learn calculus in grade school?  Just askin'   ;)


Yes, since you asked, but your presumption is faulty.


Joe

Re: ISP customer assignments

[Walter Keen]

I've got to agree with Brian, especially in an ISP environment, why 
would anyone hire or keep someone who couldn't grasp the concept of 
CIDR?  You certainly wouldn't want to have them maintaining a core 
router with lots of v4 routes, since router-router links are almost 
always numbered in subnets as small as logic dictates.


On 10/16/2009 01:58 PM, Brian Johnson wrote:

I actually think that CIDR is easier to understand than classful
addressing. Do the subject completely in binary. It makes complete sense
then.

- Brian

BTW: If the grad students don't get it, fail them! I don't want an
engineer who can't grasp basic binary math.


   

-Original Message-
From: Daniel Golding [mailto:dgold...@t1r.com]
Sent: Friday, October 16, 2009 3:51 PM
To: Joe Abley
Cc: NANOG
Subject: Re: ISP customer assignments


The big problem here is that CIDR is tough to teach, even to
engineering students. This seems bizarre and counterintuitive, but its
true. I know this because I've done it. Its really easy to teach
classful addressing, on the other hand. Other problems include the
issue that many of the folks teaching have never had to use CIDR in
real life, textbook age, and, in some cases, lack of mathematical
preparation and inclination on the part of students.

Scarier: I was teaching graduate students.

- Dan

 
   


--


Walter Keen
Network Technician
Rainier Connect
(o) 360-832-4024
(c) 253-302-0194

RE: ISP customer assignments

[Brian Johnson]

I actually think that CIDR is easier to understand than classful
addressing. Do the subject completely in binary. It makes complete sense
then.

- Brian

BTW: If the grad students don't get it, fail them! I don't want an
engineer who can't grasp basic binary math.


> -Original Message-
> From: Daniel Golding [mailto:dgold...@t1r.com]
> Sent: Friday, October 16, 2009 3:51 PM
> To: Joe Abley
> Cc: NANOG
> Subject: Re: ISP customer assignments
> 
> 
> The big problem here is that CIDR is tough to teach, even to
> engineering students. This seems bizarre and counterintuitive, but its
> true. I know this because I've done it. Its really easy to teach
> classful addressing, on the other hand. Other problems include the
> issue that many of the folks teaching have never had to use CIDR in
> real life, textbook age, and, in some cases, lack of mathematical
> preparation and inclination on the part of students.
> 
> Scarier: I was teaching graduate students.
> 
> - Dan
> 

Re: ISP customer assignments

[Daniel Golding]

The big problem here is that CIDR is tough to teach, even to  
engineering students. This seems bizarre and counterintuitive, but its  
true. I know this because I've done it. Its really easy to teach  
classful addressing, on the other hand. Other problems include the  
issue that many of the folks teaching have never had to use CIDR in  
real life, textbook age, and, in some cases, lack of mathematical  
preparation and inclination on the part of students.


Scarier: I was teaching graduate students.

- Dan

On Oct 13, 2009, at 7:53 AM, Joe Abley wrote:



On 2009-10-13, at 07:39, Scott Morris wrote:

No idea, I haven't looked at that stuff in a while.   But I would  
assume

so, as it's easier to build a foundation than jumping straight to
something difficult?


I've found RIP to be a reasonable way to teach the concept of a  
routing protocol, since the protocol is very simple and you can  
always close with "don't ever use this".


But teaching classful routing and addressing is just moronic. It's a  
foundation that nothing is built on any more, and makes no sense to  
teach outside of a history class.



Or did you learn calculus in grade school?  Just askin'   ;)


Yes, since you asked, but your presumption is faulty.


Joe

Re: ISP customer assignments

[Tore Anderson]

* Chris Adams

> This brings up something else I'm trying to figure out.  We're not a
> huge ISP; I've got our /32 but I don't see us using more.  We have two
> main POPs, each with Internet links, plus a link between the two.  Our
> IPv4 allocations are larger than the minimum, so I split our IPv4 space
> between the two POPs and avertise a smaller block out of the smaller of
> the two POPs.
> 
> This has worked okay and handles the POP-to-POP link going down; when
> that happens, our POP-to-POP traffic (not a large precentage of our
> traffic) goes across our Internet connections, but Internet traffic for
> each POP goes to directly to the POP.
> 
> With IPv6, we've got our single /32.  From what I understand, if I try
> to advertise a /33 from the smaller POP, many (most?) will drop it (if
> my upstreams even take it).  If I advertise the /32 from both routers,
> when that link goes down, my IPv6 traffic will be pretty much hosed.

What you can do is to set up a tunnel between the sites (can be
encrypted if necessary) through your upstream(s), and include it in your
IGP - making sure that it has a higher cost/metric than the dedicated
circuit.

If then the dedicated circuit goes down, the traffic between the PoPs is
redirected through the tunnel, and no connectivity is lost. You might
need to upgrade the capacity of the dedicated circuit though, since
there's no avoiding that some inbound packets will be delivered to the
wrong PoP.  Also you should make sure that the ports to your upstreams
have enough available burst capacity (and preferably a roomy
percentile-based charging scheme so that a bit of downtime on the
dedicated circuit won't cost you anything).

If you're single-homing to the the same upstream AS at both sites,
another solution is to announce the aggregate /32 from both PoPs and at
the same time a more specific route from each of them tagged with the
no-export community (assuming your upstream will accept the deaggregated
route in both locations).

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

Re: ISP customer assignments

[Rob Evans]

> This is a bit annoying though, yeah. But, I'm not sure I can think of a good
> solution that doesn't involve us changing the routing system so that we can
> handle a huge amount of intentional de-aggregates or something.

Within the RIPE region we're currently discussing a document on IPv6
route aggregation that acknowledges there are cases where it may be
necessary to break up a /32 into a limited number of smaller blocks.
Following discussion at the meeting last week I need to revise it, but
the previous draft is here:

http://www.ripe.net/ripe/maillists/archives/routing-wg/2009/msg00120.html

Cheers,
Rob

Re: ISP customer assignments

[Dave Temkin]

Nathan Ward wrote:

On 16/10/2009, at 1:17 PM, Chris Adams wrote:


Is there any good solution to this?  I don't expect us to fill the /32
to justify expanding it (although I do see ARIN appears to have left
space for up to a /29; I guess that's their sparse allocation policy?).


Your justification is that you have two sites without a guaranteed 
link between them.


This is a bit annoying though, yeah. But, I'm not sure I can think of 
a good solution that doesn't involve us changing the routing system so 
that we can handle a huge amount of intentional de-aggregates or 
something.


--
Nathan Ward

Actually, as of right now that's not justification.  The Multiple 
Discrete Networks policy that's up for a vote in Dearborn will allow for 
this, but right now there's no IPv6 equivalent of that policy.


-Dave

Re: ISP customer assignments

[William Herrin]

On Thu, Oct 15, 2009 at 8:17 PM, Chris Adams  wrote:
> With IPv6, we've got our single /32.  From what I understand,
> if I try to advertise a /33 from the smaller POP, many (most?)
> will drop it (if my upstreams even take it).  If I advertise the /32
> from both routers, when that link goes down, my IPv6 traffic
> will be pretty much hosed.
> Is there any good solution to this?

Chris,

Here's what I do with my IPv4 /24: I advertise it at higher priority
at the larger POP and a slightly lower priority at the smaller POP.
Then I got a small block of addresses from each upstream at each POP
(from their still-aggregated blocks) to anchor a set of VPNs between
the two. Something has to go disastrously wrong for me to suffer any
worse effects than the occasional inefficient routing.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: ISP customer assignments

[Nathan Ward]

On 16/10/2009, at 1:17 PM, Chris Adams wrote:


Is there any good solution to this?  I don't expect us to fill the /32
to justify expanding it (although I do see ARIN appears to have left
space for up to a /29; I guess that's their sparse allocation  
policy?).


Your justification is that you have two sites without a guaranteed  
link between them.


This is a bit annoying though, yeah. But, I'm not sure I can think of  
a good solution that doesn't involve us changing the routing system so  
that we can handle a huge amount of intentional de-aggregates or  
something.


--
Nathan Ward

Re: ISP customer assignments

[Chris Adams]

Once upon a time, Michael Dillon  said:
> And only the largest ISPs will outgrow a /32 allocation.

This brings up something else I'm trying to figure out.  We're not a
huge ISP; I've got our /32 but I don't see us using more.  We have two
main POPs, each with Internet links, plus a link between the two.  Our
IPv4 allocations are larger than the minimum, so I split our IPv4 space
between the two POPs and avertise a smaller block out of the smaller of
the two POPs.

This has worked okay and handles the POP-to-POP link going down; when
that happens, our POP-to-POP traffic (not a large precentage of our
traffic) goes across our Internet connections, but Internet traffic for
each POP goes to directly to the POP.

With IPv6, we've got our single /32.  From what I understand, if I try
to advertise a /33 from the smaller POP, many (most?) will drop it (if
my upstreams even take it).  If I advertise the /32 from both routers,
when that link goes down, my IPv6 traffic will be pretty much hosed.

Is there any good solution to this?  I don't expect us to fill the /32
to justify expanding it (although I do see ARIN appears to have left
space for up to a /29; I guess that's their sparse allocation policy?).

I guess this is traffic engineering, although I'm not deaggregating to
try to control how much goes where, just to ensure connectivity in the
face of failures.  This link has been pretty reliable lately (since the
telco re-engineered it), but it was flakey as hell a while back (when it
went through 7 companies to go between cities 90 miles apart).

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: ISP customer assignments

[Michael Dillon]

> Of course, with IPv4, you never assigned a large enough block to begin
> with that would anticipate all growth, so routing additional blocks was
> a lot easier than changing blocks, cleaner than secondary IPs
> multiplying like crazy, etc., etc.  None of that would be an issue with
> a single /64.

You've hit on the key difference of IPv6. With IPv6 you should design
your network
so that it can grow for a long time without increasing the address
block sizes anywhere.
A /64 will work for even the biggest subnets. A /48 will do for for
very, very big sites.
And only the largest ISPs will outgrow a /32 allocation. If you assign a /48 to
a data center site, then when you subnet it, try to maintain that growth ability
if you can. Don't skimp on address block sizes unless you are backed into
a corner for technical or business reasons.

--Michael Dillon

Re: ISP customer assignments

[Dan White]

I can't offer any knowledgeable advice about PPPoA/E. We have never used
it ourselves.

On 14/10/09 22:16 -0500, Frank Bulk wrote:

So you're saying moving away from PPPoA/E and just going bridged?

Frank

-Original Message-
From: Dan White [mailto:dwh...@olp.net] 


Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet
QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or
Cisco.


--
Dan White

RE: ISP customer assignments

[Frank Bulk]

So you're saying moving away from PPPoA/E and just going bridged?

Frank

-Original Message-
From: Dan White [mailto:dwh...@olp.net] 
Sent: Tuesday, October 13, 2009 9:15 AM
To: Justin Shore
Cc: nanog@nanog.org
Subject: Re: ISP customer assignments

On 12/10/09 21:34 -0500, Justin Shore wrote:
> To go along with Dan's query from above, what are the preferred methods  
> that other SPs are using to deploy IPv6 with non-IPv6-capable edge  
> hardware?  We too have a very limited number of dialup customers and  
> will never sink another dollar in the product.  Unfortunately I also  
> have brand-new ADSL2+ hardware that doesn't support IPv6 and according  
> to the vendors (Pannaway) never will. 

I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix
of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda
in the same boat, but we expect to be able to gracefully transition to dual
stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring
the modems into bridged mode and leaving the layer 3 up to the customer's
router.

We're also in the process of budgeting for a new broadband aggregation
router next year that will handle IPv6. 

Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet
QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or
Cisco.

-- 
Dan White

Re: ISP customer assignments

[Mark Andrews]

In message , Nathan Ward writes
:
> 
> On 14/10/2009, at 7:23 PM, Mark Andrews wrote:
> 
> > DS-Lite is there for when the ISP runs out of IPv4 addresses to
> > hand one to each customer.  Many customers don't need a unique IPv4
> > address, these are the ones you switch to DS-Lite.  Those that do
> > require a unique IPv4 you leave on full dual stack for as long as
> > you can.
>
> The authors of DS-lite say it's because running a dual stack network  
> is hard.

It is harder.

> You clearly don't share that view, so in your view what's wrong with  
> dual stack with IPv4 for everyone then, whether they need a unique  
> address or not?

Dual stack for everyone was feasible 5 years ago.  It isn't anymore,
that transition plan has sailed and almost no one got on board.

Because there aren't enough addresses to go around and there hasn't
been for years.  PNAT is a kludge to work around that fact.  When
you can't give every customer their own IPv4 address yet you still
need to provide IPv4 connectivity you need to work out how to share
those addresses you have efficiently.  Given double PNAT or DS-Lite
I know which one I prefer.

DS-Lite allows lots of the tricks used with PNAT to continue to
work.  Those tricks will just stop working with double PNAT.
 
> DS-lite requires CGN, so does dual stack without enough IPv4 addresses.
> 
> This is probably the wrong forum for a DS-lite debate. I'm sure people  
> have a use for it, they actually might have gear that can only do IPv4  
> OR IPv6 but not both or something.
> My problem with it is that it's being seen as a solution for a whole  
> lot of people, when in reality it's a solution for a small number of  
> people.

It's not the only solution.  There are others and customers and
ISP's will need to work out what is best for their collective
requirements.

It is a reasonable fit for residentual ISP's as the CPE PNAT is
really very inefficient at conserving addresses and by splitting
the PNAT across 2 co-operating boxes you can get the address
utilisation efficency we now need in IPv4 to cover all the short
sightedness that has got us to the place where we need things other
than dual stack.

> Thanks for the point about the tunnel brokers though, I missed that,  
> I'll update this tomorrow with any suggestions I get before then.
> 
> --
> Nathan Ward
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP customer assignments

[Nathan Ward]

On 14/10/2009, at 7:23 PM, Mark Andrews wrote:


DS-Lite is there for when the ISP runs out of IPv4 addresses to
hand one to each customer.  Many customers don't need a unique IPv4
address, these are the ones you switch to DS-Lite.  Those that do
require a unique IPv4 you leave on full dual stack for as long as
you can.
The authors of DS-lite say it's because running a dual stack network  
is hard.


You clearly don't share that view , so in your view what's wrong with  
dual stack with IPv4for everyone then, whether they need a unique  
address or not?


DS-lite requires CGN, so does dual stack without enough IPv4 addresses.

This is probably the wrong forum for a DS-lite debate. I'm sure people  
have a use for it, they actually might have gear that can only do IPv4  
OR IPv6 but not both or something.
My problem with it is that it's being seen as a solution for a whole  
lot of people, when in reality it's a solution for a small number of  
people.




Thanks for the point about the tunnel brokers though, I missed that,  
I'll update this tomorrow with any suggestions I get before then.


--
Nathan Ward

RE: ISP customer assignments

[Wouter de Jong]

In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris
Adams wrote:

<..>

> What about web-hosting type servers?  Right now, I've got a group of
> servers in a common IPv4 subnet (maybe a /26), with a /24 or two
routed
> to each server for hosted sites.  What is the IPv6 equivalent?  I can
> see a /64 for the common subnet, but what to route for aliased IPs for
> web hosts?  It is kind of academic right now, since our hosting
control
> panel software doesn't handle IPv6, but I certainly won't be putting
> 2^64 sites on a single server.  Use a /112 here again as well?  Use a
> /64 per server because I can?


I'd be interested in any suggestions on this part as well.

We're a Hosting provider and basicly we have (for now) 
3 different product-groups we want to launch IPv6 on :

1 - Shared Hosting
These servers (Linux), are all in 1 vlan.
Each server has 1 IPv4 address from the subnet that's configured on the
vlan.
Then we have an IPv4 /24 routed to each of the servers 
(each server has 1 /24 to host sites on).

Here I'd assign a single /64 and use static addressing.


2 - Premium Managed & Unmanaged Hosting (Co-location).
Each customer has one (or more) dedicated subnets and vlans.

Here I'd assign a /64 per vlan.
I'd do static addressing for Managed, but probably provide 
RA (EUI-64) for Unmanaged.


3 - Managed and Umanaged Hosting (Co-location).
These servers are in 'shared' subnets, ranging from /23 to /26, 
and each customer get's assigned at least 1 IP from this subnet 
and more if they can justify. For customers needing 'large' subnets, 
we'd route a different subnet to their server of choice.

Here, I'm not sure what to do...


You should at least assign a /64 per customer, but how would one do that

when they are in shared subnets/vlans... ?

If for every server I'd need to assign a /64 secondary to our vlan
interfaces,
I'd trip the maximums 
(Nortel Passport 8600 used for these customers has quite some
limitations on IPv6).
It would be nice though, cause once IPv4 is no longer used (...) we
could 
move customers to another/dedicated vlan.

We've also fiddled with the idea of assigning one /48 to each of these
vlans, 
and let each 'server' use a /64 out of it. This still seems a bit weird
though...

Also, since we do IP based billing here, 
we'd never know if one has 'hijacked' some IP space.

Yes, we'd know for un-assigned addresses 
(not assigned but has traffic -> alert), 
but I don't expect a customer to use all addresses out of 'their' /64,
so the not used addresses could be easily be abused.

For IPv4, all addresses are usually really used and the customer 
who's IP's are hijacked, would almost definitely hang on the phone in
no-time.


Some advice would be very appreciated.


Best regards,

Wouter de Jong
WideXS

Re: ISP customer assignments

[Mark Andrews]

In message , Nathan Ward writes:
> Ok, I've decided to do this a different way to my usual ranting.  
> Instead of explaining the options over and over and hoping people can  
> make sense of the complexities of it, become experts, and make good  
> informed decisions, I've made a flow chart. Feel free to ask about  
> details and I can get in to the ranting part, this is really a place  
> to start.
> 
> Right now it assumes people only provide DSL or other dynamic sort of  
> services.
> It also assumes DS-Lite people are insane, so probably need better  
> language there.

DS-Lite is there for when the ISP runs out of IPv4 addresses to
hand one to each customer.  Many customers don't need a unique IPv4
address, these are the ones you switch to DS-Lite.  Those that do
require a unique IPv4 you leave on full dual stack for as long as
you can.

You forgot the tunnel brokers.

> Also the first question is not necessarily about who you are, but who  
> is driving the IPv6 'build' - which is why native, 6rd and ds-lite are  
> not appropriate for the customer-driven side. I hope that makes sense.
> No talk about ISATAP and stuff for inside the customer network either.  
> And before you ask no ISATAP is not appropriate for ISPs, doesn't work  
> through NAT.
> 
> Anyway:
> - 6RD is used by free.fr. Not widely implemented by anyone yet.
> - DS-Lite is something some guys at Comcast and others are talking  
> about. Not widely implemented by anyone yet.
> - The rest you can figure out from wikipedia and stuff.
> 
> Please email me with any corrections, complaints, or threats if you're  
> a DS-Lite fan. I'll always keep old versions in this directory, and  
> the latest version will always have this filename, so please link to  
> it instead of copying it, etc. etc.:
> 
> http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-current.pdf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: ISP customer assignments

[Nathan Ward]

Ok, I've decided to do this a different way to my usual ranting.  
Instead of explaining the options over and over and hoping people can  
make sense of the complexities of it, become experts, and make good  
informed decisions, I've made a flow chart. Feel free to ask about  
details and I can get in to the ranting part, this is really a place  
to start.


Right now it assumes people only provide DSL or other dynamic sort of  
services.
It also assumes DS-Lite people are insane, so probably need better  
language there.
Also the first question is not necessarily about who you are, but who  
is driving the IPv6 'build' - which is why native, 6rd and ds-lite are  
not appropriate for the customer-driven side. I hope that makes sense.
No talk about ISATAP and stuff for inside the customer network either.  
And before you ask no ISATAP is not appropriate for ISPs, doesn't work  
through NAT.


Anyway:
- 6RD is used by free.fr. Not widely implemented by anyone yet.
- DS-Lite is something some guys at Comcast and others are talking  
about. Not widely implemented by anyone yet.

- The rest you can figure out from wikipedia and stuff.

Please email me with any corrections, complaints, or threats if you're  
a DS-Lite fan. I'll always keep old versions in this directory, and  
the latest version will always have this filename, so please link to  
it instead of copying it, etc. etc.:


http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-current.pdf


On 13/10/2009, at 11:26 PM, Adrian Chadd wrote:


Nathan Ward, please stand up.



Adrian

On Tue, Oct 13, 2009, TJ wrote:


-Original Message-
From: Justin
To go along with Dan's query from above, what are the preferred  
methods

that other SPs are using to deploy IPv6 with non-IPv6-capable edge
hardware?  We too have a very limited number of dialup customers and
will never sink another dollar in the product.  Unfortunately I also
have brand-new ADSL2+ hardware that doesn't support IPv6 and  
according

to the vendors (Pannaway) never will.  We also have CMTSs that don't
support IPv6, even though they too are brand-new.  Those CMTSs top  
out

at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs
regardless of the underlying CM's IPv6 support or lack thereof (like
Cisco allowed for example).  Are providers implementing tunneling
solutions?  Pros/cons of the various solutions?


My first (potentially ignorant) response would be to get your  
acquisitions



people aligned with your business, and by that I mean they should be

making
a concerted effort to only buy IPv6 capable gear, especially when  
IPv6 is



coming to you within that gears lifecycle.
I guess your customers will need to tunnel, as long as you give  
them a

public
IP they have 6to4 (and possibly Teredo, tunnel broker) - but  
native is

better.




--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial  
Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available  
in WA -



!DSPAM:22,4ad455ce140151847938845!

Re: ISP customer assignments

[Joel Jaeggli]

Chris Adams wrote:
> I guess I'm missing something; what in section 3 is this referring to?
> I can understand /64 or /126 (or maybe /124 if you were going to
> delegate reverse DNS?), but why /112 and "16 bits for node identifiers"
> on a point-to-point link?

It falls on a 16 bit boundry and is therefore easy to read. some
numbering concessions within a vast space exist for the convenience of
the poor humans not the machines. I can pick out the host side of the
address in a /64 no problem but for some reason I have a trouble finding
subnet boundaries on a series of /93s.

Re: ISP customer assignments

[Nathan Ward]

On 14/10/2009, at 3:49 PM, Chris Adams wrote:


Once upon a time, Nathan Ward  said:

On 14/10/2009, at 2:14 PM, Chris Adams wrote:

What about web-hosting type servers?  Right now, I've got a group of
servers in a common IPv4 subnet (maybe a /26), with a /24 or two
routed
to each server for hosted sites.  What is the IPv6 equivalent?  I  
can
see a /64 for the common subnet, but what to route for aliased IPs  
for

web hosts?  It is kind of academic right now, since our hosting
control
panel software doesn't handle IPv6, but I certainly won't be putting
2^64 sites on a single server.  Use a /112 here again as well?   
Use a

/64 per server because I can?


Why route them to the servers? I would just put up a /64 for the web
servers and bind addresses to your ethernet interface out of that /64
as they are used by each site.
I guess you might want to route them to the servers to save ND  
entries

or something on your router?


In the past, we saw issues with thousands of ARP entries (it has  
been a
while and I don't remember what issues now though).  Moving a block  
from

one server to another didn't require clearing an ARP cache (and
triggering a couple of thousand new ARP requests).


Yeah I figured as much.


Also, it is an extra layer of misconfiguration-protection: if the IPs
are routed, accidentally assigning the wrong IP on the wrong server
didn't actually break any existing sites (and yes, that is a lesson  
from

experience).


I guess. The advantage of doing it with a single /64 for all of them  
is that you can move individual sites to other servers without much  
drama. That might not be useful for everyone of course.


--
Nathan Ward

Re: ISP customer assignments

[Chris Adams]

Once upon a time, Nathan Ward  said:
> On 14/10/2009, at 2:14 PM, Chris Adams wrote:
> >What about web-hosting type servers?  Right now, I've got a group of
> >servers in a common IPv4 subnet (maybe a /26), with a /24 or two  
> >routed
> >to each server for hosted sites.  What is the IPv6 equivalent?  I can
> >see a /64 for the common subnet, but what to route for aliased IPs for
> >web hosts?  It is kind of academic right now, since our hosting  
> >control
> >panel software doesn't handle IPv6, but I certainly won't be putting
> >2^64 sites on a single server.  Use a /112 here again as well?  Use a
> >/64 per server because I can?
> 
> Why route them to the servers? I would just put up a /64 for the web  
> servers and bind addresses to your ethernet interface out of that /64  
> as they are used by each site.
> I guess you might want to route them to the servers to save ND entries  
> or something on your router?

In the past, we saw issues with thousands of ARP entries (it has been a
while and I don't remember what issues now though).  Moving a block from
one server to another didn't require clearing an ARP cache (and
triggering a couple of thousand new ARP requests).

Also, it is an extra layer of misconfiguration-protection: if the IPs
are routed, accidentally assigning the wrong IP on the wrong server
didn't actually break any existing sites (and yes, that is a lesson from
experience).

Of course, with IPv4, you never assigned a large enough block to begin
with that would anticipate all growth, so routing additional blocks was
a lot easier than changing blocks, cleaner than secondary IPs
multiplying like crazy, etc., etc.  None of that would be an issue with
a single /64.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: ISP customer assignments

[Nathan Ward]

On 14/10/2009, at 2:14 PM, Chris Adams wrote:


What about web-hosting type servers?  Right now, I've got a group of
servers in a common IPv4 subnet (maybe a /26), with a /24 or two  
routed

to each server for hosted sites.  What is the IPv6 equivalent?  I can
see a /64 for the common subnet, but what to route for aliased IPs for
web hosts?  It is kind of academic right now, since our hosting  
control

panel software doesn't handle IPv6, but I certainly won't be putting
2^64 sites on a single server.  Use a /112 here again as well?  Use a
/64 per server because I can?


Why route them to the servers? I would just put up a /64 for the web  
servers and bind addresses to your ethernet interface out of that /64  
as they are used by each site.
I guess you might want to route them to the servers to save ND entries  
or something on your router?


--
Nathan Ward

Re: ISP customer assignments

[Mark Andrews]

In message , "Ricky Beam" writes:
> On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore   
> wrote:
> > He didn't really give much of a reason for the /127s yet.  I think it's  
> > coming up in a later session.  I think it basically boiled down to  
> > whether or not the customer would actually use anything bigger.  I'll  
> > write back when we get into that discussion.
> 
> It's the IPv6 equiv of an IPv4 /30 link network.  Then a /64 or whatever  
> can be aimed to that link address.  This is exactly what Bellsouth does  
> for business DSL: the link has a dynamic address and your netblock is then  
> routed to it. (this is confusing and unworkable for a lot of cheap  
> hardware.)

Just use a /64 for the customer link.  That allows them to have a CGA if
they need one.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: ISP customer assignments

[TJ]

" What about anycast-type addresses (e.g. DNS servers)?  I route a few
server IPv4 /32s around in my network; do you assign a /128, a /64 (with
only one address in use), a /112, or something else?"


Yes, on any sort of multi-access segment you really should use /64s.  
A little less stringent on an all router segment perhaps, but even then I
shoot for /64s on anything that is not a PtP link ... 


/TJ

-Original Message-
From: Chris Adams [mailto:cmad...@hiwaay.net] 
Sent: Tuesday, October 13, 2009 9:15 PM
To: nanog@nanog.org
Subject: Re: ISP customer assignments

Once upon a time, Leo Bicknell  said:
> 2) Colon's separate 16 bit chunks in IPv6.  /112's allow ::1,
>::2 to be your IP's.

Yeah, this is what I forgot about.  Makes sense now.

Another (quite possibly dumb :-) ) few questions come to mind about IPv6
assignment:

I would expect you just assign static addresses to servers.  Are there
pros/cons to using /64 or something else there?  If I'm statically
assigning IP (and DNS, etc. servers) info, why would I not just
configure the gateway there as well (especially if you just make all
local router interfaces ::1)?

What about web-hosting type servers?  Right now, I've got a group of
servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed
to each server for hosted sites.  What is the IPv6 equivalent?  I can
see a /64 for the common subnet, but what to route for aliased IPs for
web hosts?  It is kind of academic right now, since our hosting control
panel software doesn't handle IPv6, but I certainly won't be putting
2^64 sites on a single server.  Use a /112 here again as well?  Use a
/64 per server because I can?

What about anycast-type addresses (e.g. DNS servers)?  I route a few
server IPv4 /32s around in my network; do you assign a /128, a /64 (with
only one address in use), a /112, or something else?

Re: ISP customer assignments

[Leo Bicknell]

In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams 
wrote:
> I would expect you just assign static addresses to servers.  Are there
> pros/cons to using /64 or something else there?  If I'm statically
> assigning IP (and DNS, etc. servers) info, why would I not just
> configure the gateway there as well (especially if you just make all
> local router interfaces ::1)?

All of our servers are in binary coded hex. :)  That is, if your IPv4
address is 10.12.3.187, your IPv6 address is A:B:C:D::187.  The router
is ::1, just as in IPv4, and servers have static routes.

We still use /64's everywhere.  You may want to use temporary (privacy)
addresses outbound.  You many want to allow a server to use EUI-64 to
get an address while doing an install, or similar.

> What about anycast-type addresses (e.g. DNS servers)?  I route a few
> server IPv4 /32s around in my network; do you assign a /128, a /64 (with
> only one address in use), a /112, or something else?

/128's for loopbacks, anycast addreses, and similar here. Typically out
of a loopback /64.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpZg7bmq3t4a.pgp
Description: PGP signature

Re: ISP customer assignments

[Ricky Beam]

On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore   
wrote:
He didn't really give much of a reason for the /127s yet.  I think it's  
coming up in a later session.  I think it basically boiled down to  
whether or not the customer would actually use anything bigger.  I'll  
write back when we get into that discussion.


It's the IPv6 equiv of an IPv4 /30 link network.  Then a /64 or whatever  
can be aimed to that link address.  This is exactly what Bellsouth does  
for business DSL: the link has a dynamic address and your netblock is then  
routed to it. (this is confusing and unworkable for a lot of cheap  
hardware.)

Re: ISP customer assignments

[Chris Adams]

Once upon a time, Leo Bicknell  said:
> 2) Colon's separate 16 bit chunks in IPv6.  /112's allow ::1,
>::2 to be your IP's.

Yeah, this is what I forgot about.  Makes sense now.

Another (quite possibly dumb :-) ) few questions come to mind about IPv6
assignment:

I would expect you just assign static addresses to servers.  Are there
pros/cons to using /64 or something else there?  If I'm statically
assigning IP (and DNS, etc. servers) info, why would I not just
configure the gateway there as well (especially if you just make all
local router interfaces ::1)?

What about web-hosting type servers?  Right now, I've got a group of
servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed
to each server for hosted sites.  What is the IPv6 equivalent?  I can
see a /64 for the common subnet, but what to route for aliased IPs for
web hosts?  It is kind of academic right now, since our hosting control
panel software doesn't handle IPv6, but I certainly won't be putting
2^64 sites on a single server.  Use a /112 here again as well?  Use a
/64 per server because I can?

What about anycast-type addresses (e.g. DNS servers)?  I route a few
server IPv4 /32s around in my network; do you assign a /128, a /64 (with
only one address in use), a /112, or something else?

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: ISP customer assignments

[James Hess]

On Tue, Oct 13, 2009 at 6:34 PM, Cord MacLeod  wrote:

> IPv4?  What's the point of a /64 on a point to point link?  I'm not clear

IP Addressing uniformity and simplicity.

Use of  /127s  for   Point-to-Point  links  introduces  addressing
complexity that may be avoided  in V6:  the scarcity of  IPs
necessitated it in V4 .At least  /112   lies on an  even 16-bit
boundary, and that makes it  the longest prefix that is a very good
choice,  if you do need a non-standard mask.

Unless you have only a /32  of V6 space and  1 billion P2Pt links you
need (or similar scenario), there is no  utility in  practicing
rampant prefix length expansion, for the purpose of conservation
(there may be other reasons  such as preventing autoconfig).


> For all intensive purposes a /126 translates to a /30
> in IPv4.  Do people assign /24's to their point to point links today with

Not really;  there's a massive difference of scale.Say there's a
big vat that contains all gold in the universe,  you get to bring home
one  bucket of gold flakes to allocate to your customers.

In the V4 universe, well you got a /19..   You got a 60 kilogram
bucket,  and a /30  represents a 1  troy ounce scoop  taken out of
that bucket..

In the V6 universe, even if you got a measly /48:   one   /64  from that
is a 1 troy ounce gold flake out of your  2000  kilogram bucket.
Should you really be worried about cutting up that flake?

In reality... if you're an ISP the worst you have is a /32,  you can
think of a  /48  that way,   you do have  65536 of those  /48s,  also
known as a
133,588,416kg  bucket,  since  your  /32   has a maximum of   4 billion  /64s.


Normally when you have a P2P link,  it will mean you connect an end
site also: that end site gets a  /48   (Per the justification that
allows you as an ISP to get a /32,  such a large allocation).   After
assigning  65536  /64s, or 256  /64s  (if you give out /56s  to end
sites)  which you already do for each _end site_ as
standard address allocation  practice in V6,  what's another  single
/64,  seriously?



--
-J

Re: ISP customer assignments

[Leo Bicknell]

In a message written on Tue, Oct 13, 2009 at 06:26:20PM -0500, Chris Adams 
wrote:
>The author feels that if /64 cannot be used, /112, reserving the last
>16 bits for node identifiers, has probably the least amount of
>drawbacks (also see section 3).
> 
> I guess I'm missing something; what in section 3 is this referring to?
> I can understand /64 or /126 (or maybe /124 if you were going to
> delegate reverse DNS?), but why /112 and "16 bits for node identifiers"
> on a point-to-point link?

We use /112's, and do so for two (and a half) reasons:

1) If you think of all possible "network to network" interconnects
   they include the simple case like a single router on both ends,
   but they also include cases like two routers on one or both ends,
   and optionally with VRRP/HSRP.  Maximally it appears 6 IP's
   may be required (two routers both ends, plus vrrp on each,
   statics at the VRRP).

   So it makes sense to have a 8 or 16 block of IP's per link so you
   never have to renumber the link if you switch these configurations.

2) Colon's separate 16 bit chunks in IPv6.  /112's allow ::1,
   ::2 to be your IP's.

The half a reason, if you have a /64 dedicate to point to point
links, and use /112's,  you have 2^(112-64) possible links.  That's
281 trillion point to point links.  Given 1, and 2, and the numbers
/127's, /126's, /125's don't make any sense when you can standardize
on one size fits all, and never run out.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpoNZzF1ehvR.pgp
Description: PGP signature

Re: ISP customer assignments

[Scott Morris]

While entirely possible, I actually view it going the other way.  RFC
3627 points out some nice issues as far as DAD and anycast operation is
concerned, but what I'd see (just my random opinion as I haven't
bothered to write an RFC) is that it would make entirely much more sense
to come up with a structure to STOP the anycast performance on a link
that is point-to-point. 

While there are 340 undecillion addresses, that doesn't mean we need to
waste a /64 on a link that will possibly only have two addresses anyway.

My two cents.

Scott


eric clark wrote:
> So far, I have only dabbled with IPv6, but my reading of the RFCs is that
> VLSM for lengths beyond /64 is not required. Subsequently, to use anything
> longer is an enormous gamble in an enterprise environment. I envision
> upgrading code one day and finding that your /127 isn't supported any more
> and they forgot to mention it. I'll stick to /64, though it does seem a
> horrible waste of space.
>
> Someone else might have read the RFC differently though.
>
>
> Eric Clark
>
>   

Re: ISP customer assignments

[Scott Morris]

That was the point.  :)

Scott

Matthew Petach wrote:
>
>
> On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris  > wrote:
>
> How many addresses do you like on point-to-point circuits?
>
> Scott
>
>
> I allocate a /64, but currently I configure only a /127 subnet on the
> actual interface.  That prevents the neighbor table explosion/NS/ND
> traffic flooding challenges that can occur otherwise if you configure
> the link as a /64, and some not-nice person decides to start ping
> sweeping or nmapping the subnet; your router has to send out NS
> messages for every address in the /64 being probed, update the
> neighbor table with the incomplete entry, then flush it out when
> no ND message is seen.  On a point-to-point link between
> routers you're never going to run stateless autoconfiguration,
> so there's not much downside to configuring it as a /127.
>
> Still...just in case, I do allocate the whole /64 for the link, so
> that if in the future it turns out that for some reason it really,
> *really* does have to be a /64 configured on it, I can make the
> change just by adjusting masks on each end, rather than
> having to actually renumber the entire network.
>
> *shrug*  As always, your mileage will vary, but this has
> worked out well for me so far.
>
> Matt
>

Re: ISP customer assignments

[Kevin Loch]

Chris Adams wrote:

I guess I'm missing something; what in section 3 is this referring to?
I can understand /64 or /126 (or maybe /124 if you were going to
delegate reverse DNS?), but why /112 and "16 bits for node identifiers"
on a point-to-point link?


The only thing special about /112 is that it is on a ":" boundary
so it makes for some nice numbering plans:

Let's say you set aside 2001::0:1::/64 for /112's

link 1:
2001::0:1::1:1
2001::0:1::1:2

link 2:
2001::0:1::2:1
2001::0:1::2:2

This :1, :2 arrangement seems to be common but for internal links you
could make the last hextet be a unique id for the specific router.
That could use more than a few bits in a large network.

- Kevin

Re: ISP customer assignments

[Cord MacLeod]

On Oct 13, 2009, at 4:26 PM, Chris Adams wrote:


Once upon a time, Michael Dillon  said:

How many addresses do you like on point-to-point circuits?


That will become one of those great interview questions, because  
anyone who says

something like "a /127" or "a /64" will be someone that you probably
don't want to hire.

The right answer is to explain that there are some issues surrounding
the choice of
addressing on point-to-point circuits and there has even been an RFC
published discussing
these issues, RFC 3627 


Still learning here, so please go easy...

I read the above, and I see section 4 item 3 says:

  The author feels that if /64 cannot be used, /112, reserving the  
last

  16 bits for node identifiers, has probably the least amount of
  drawbacks (also see section 3).

I guess I'm missing something; what in section 3 is this referring to?
I can understand /64 or /126 (or maybe /124 if you were going to
delegate reverse DNS?), but why /112 and "16 bits for node  
identifiers"

on a point-to-point link?


I'm actually completely unclear why people would use anything but a / 
126 in 90% or more of cases.  For all intensive purposes a /126  
translates to a /30 in IPv4.  Do people assign /24's to their point to  
point links today with IPv4?  What's the point of a /64 on a point to  
point link?  I'm not clear why people would intentionally be so  
frivolous with their IP space simply for the sake of "because I can."

Re: ISP customer assignments

[Chris Adams]

Once upon a time, Michael Dillon  said:
> > How many addresses do you like on point-to-point circuits?
> 
> That will become one of those great interview questions, because anyone who 
> says
> something like "a /127" or "a /64" will be someone that you probably
> don't want to hire.
> 
> The right answer is to explain that there are some issues surrounding
> the choice of
> addressing on point-to-point circuits and there has even been an RFC
> published discussing
> these issues, RFC 3627 

Still learning here, so please go easy...

I read the above, and I see section 4 item 3 says:

   The author feels that if /64 cannot be used, /112, reserving the last
   16 bits for node identifiers, has probably the least amount of
   drawbacks (also see section 3).

I guess I'm missing something; what in section 3 is this referring to?
I can understand /64 or /126 (or maybe /124 if you were going to
delegate reverse DNS?), but why /112 and "16 bits for node identifiers"
on a point-to-point link?
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: ISP customer assignments

[Adam Armstrong]

eric clark wrote:

So far, I have only dabbled with IPv6, but my reading of the RFCs is that
VLSM for lengths beyond /64 is not required. Subsequently, to use anything
longer is an enormous gamble in an enterprise environment. I envision
upgrading code one day and finding that your /127 isn't supported any more
and they forgot to mention it. I'll stick to /64, though it does seem a
horrible waste of space.

Someone else might have read the RFC differently though.
  
I'm sure there's an RFC somewhere talking about Classful addressing 
pre-CIDR. Perhaps we should stop using CIDR in IPv4. It might stop 
working one day. ;)


Operational reality helps to refine RFCs. Many people are already using 
longer prefixes for infrastructure and other purposes, so it's unlikely 
to go away. The only real issue is that some old hardware may not 
support prefixes longer than /64 in hardware and so may drop to software 
routing.


I don't know of any examples of this though.

adam.

Re: ISP customer assignments

[eric clark]

So far, I have only dabbled with IPv6, but my reading of the RFCs is that
VLSM for lengths beyond /64 is not required. Subsequently, to use anything
longer is an enormous gamble in an enterprise environment. I envision
upgrading code one day and finding that your /127 isn't supported any more
and they forgot to mention it. I'll stick to /64, though it does seem a
horrible waste of space.

Someone else might have read the RFC differently though.


Eric Clark

Re: ISP customer assignments

[Justin Shore]

Dan White wrote:

Occam did it partially right. They're half-bridging only - not true layer 2
to an aggregator (which is not necessary in their scenario). The problem
with the access vendor doing half-bridging is that they have to be very
layer-3 smart, and Occam was not quite there for IPv6 last time I worked
with them (about 6 months ago).


When we did a RFP with them they didn't support v6 yet but they also 
wouldn't get in the way of passing v6 over them (minus the DHCP 
snooping/learning features of course).  That was 2 years ago.  I haven't 
looked at them since but they said that they'd work on it.



I haven't really been happy with any DSL vendor's response to my questions
about IPv6. We happened to choose Calix, which is not particularly IPv6
friendly, but were successful in getting commitments from them to support
IPv6 pass through.


None of the FTTH vendors we vetted supported v6 but at least a few said 
that they'd work on it.  Pannaway's response though was priceless.



I have little doubt that Pannaway could implement IPv6, they just need to
get enough demand from customers to make it worth their while.


Pannaway was bought a while back by Enablence.  Hopefully they will 
drive a bit more clue into the products.  Hopefully that SE isn't there 
anymore or if he is hopefully he's not driving product development.  His 
other 2 answers about QoS not being needed because our links were 
sustaining saturation (microbursts anyone?) and that we didn't need an 
IGP because our network wasn't big enough and that static routing would 
do (for just shy of 100 routing devices in 3 POPs) was the icing on the 
cake.  Unfortunately the decision was made to eat the cake anyway.


Justin

Re: ISP customer assignments

[Dan White]

On 13/10/09 15:32 -0500, Justin Shore wrote:
one like the BARs.  Occam did it right.  They didn't try to pretend to be 
in the router business.  They stuck with L2.


Occam did it partially right. They're half-bridging only - not true layer 2
to an aggregator (which is not necessary in their scenario). The problem
with the access vendor doing half-bridging is that they have to be very
layer-3 smart, and Occam was not quite there for IPv6 last time I worked
with them (about 6 months ago).

It's no secret; I do not recommend Pannaway products based on my  
firsthand experience.  Their SE actually told us 2 years ago that IPv6  
was a fad and would never be adopted.


I haven't really been happy with any DSL vendor's response to my questions
about IPv6. We happened to choose Calix, which is not particularly IPv6
friendly, but were successful in getting commitments from them to support
IPv6 pass through.

I have little doubt that Pannaway could implement IPv6, they just need to
get enough demand from customers to make it worth their while.

--
Dan White

Re: ISP customer assignments

[Justin Shore]

Dan White wrote:

I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix
of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda
in the same boat, but we expect to be able to gracefully transition to dual
stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring
the modems into bridged mode and leaving the layer 3 up to the customer's
router.

We're also in the process of budgeting for a new broadband aggregation
router next year that will handle IPv6.
Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet
QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or
Cisco.


In Pannaway's case they want to pretend to be in the router business and 
we ended up buying their BARs.  Their DSLAMs (BASs) are aggregated into 
their BARs and the BAR ring terminates on my Cisco core.  I would love 
to eliminate the BARs from the equation but that's not an option.  I've 
been by several (dozen) people that their Minnesota Pannaway office 
stopped selling the BARs and instead worked with Cisco for aggregation. 
 I've also been told by Cisco folks that numerous sites are trying to 
get Cisco to take the Pannaway BARs in on trade-in.  It would appear 
that no one like the BARs.  Occam did it right.  They didn't try to 
pretend to be in the router business.  They stuck with L2.


We're also in a bit of a pickle because we're using "smart" DSL 
modems/routers.  I've argued for years for dumb DSL modems that had no 
routing/NAT capabilities at all.  Unfortunately I didn't win that 
argument.  Now we have what amount to CPEs that do not support IPv6. 
Whether they'll even pass IPv6 packets in a bridging mode is yet to be 
determined.  Since some of the modems are Pannaway and given my 
experience with Pannaway and trying to bridge things over it without 
Pannaway messing with it in the middle (VLAN carrying IS-IS for 
example), I fully expect problems...


It's no secret; I do not recommend Pannaway products based on my 
firsthand experience.  Their SE actually told us 2 years ago that IPv6 
was a fad and would never be adopted.


Justin

Re: ISP customer assignments

[Marco Hogewoning]

On Oct 13, 2009, at 9:56 PM, Joe Abley wrote:



On 2009-10-13, at 14:46, Matthew Petach wrote:


I allocate a /64, but currently I configure only a /127 subnet on the
actual interface.


For BRAS/PPPoE deployments you're dealing with a point-to-point  
link, so in principle you can number the endpoints using whatever  
you want. They're just host addresses and interface routes when it  
comes down to it. There's no need to number both ends within a  
single conventional subnet.


In the test deployment I did earlier in the year I defined a pool of  
link addresses per BRAS (one /64 prefix per BRAS) and handed out one  
to each subscriber using ND/RA after IPv6CP had completed. To the  
subscriber that looked like a /128 host route, with some other  
arbitrary address on the far side. (We could have done it with  
RADIUS too, but having a static link address didn't seem  
particularly important.)


A sub-side static /48 was then assigned via RADIUS and a route  
installed on the BRAS side, with DHCPv6 PD available as an option  
for clients who want auto-configuration rather than static config.


It seemed to work. BRAS was a Juniper E-series (test box was an  
ERX310).



We run roughly the same, although we skip the whole globalscope  
address on the PPP, running localscope only works for the CPE we  
tested so far.


MarcoH

Re: ISP customer assignments

[Joe Abley]

On 2009-10-13, at 14:46, Matthew Petach wrote:


I allocate a /64, but currently I configure only a /127 subnet on the
actual interface.


For BRAS/PPPoE deployments you're dealing with a point-to-point link,  
so in principle you can number the endpoints using whatever you want.  
They're just host addresses and interface routes when it comes down to  
it. There's no need to number both ends within a single conventional  
subnet.


In the test deployment I did earlier in the year I defined a pool of  
link addresses per BRAS (one /64 prefix per BRAS) and handed out one  
to each subscriber using ND/RA after IPv6CP had completed. To the  
subscriber that looked like a /128 host route, with some other  
arbitrary address on the far side. (We could have done it with RADIUS  
too, but having a static link address didn't seem particularly  
important.)


A sub-side static /48 was then assigned via RADIUS and a route  
installed on the BRAS side, with DHCPv6 PD available as an option for  
clients who want auto-configuration rather than static config.


It seemed to work. BRAS was a Juniper E-series (test box was an ERX310).


Joe

Re: ISP customer assignments

[Michael Dillon]

> I'm ok with teaching it to beginners to explain where we came from but that
> should be it.

But why does that have to be done first? Why can't they teach current best
practice in addressing, and then point out that historically it was
done different
but that caused problems which led to today's system?

>  That said I still occasionally refer to networks in classful terms
> and I can think of several network engineers who have years of enterprise
> experience that still don't understand CIDR.

I'm very careful about classful terminology because I work with a team
of engineers
who still occasionally must deal with a customer network (using very old gear)
which requires class C addressing.

For those who don't know what a Class C address is, it is an IP address in the
range 192.0.0.0 to 223.255.255.255, i.e. it begins with binary 110, and the
network prefix is fixed at /24. This means that 10.2.3/24 is not a class C
address, and 192.2/16 is not a legal address block.

--Michael Dillon

Re: ISP customer assignments

[Michael Dillon]

> How many addresses do you like on point-to-point circuits?

That will become one of those great interview questions, because anyone who says
something like "a /127" or "a /64" will be someone that you probably
don't want to hire.

The right answer is to explain that there are some issues surrounding
the choice of
addressing on point-to-point circuits and there has even been an RFC
published discussing
these issues, RFC 3627 

The right decision for one network, or for one point in the topology,
might not be the
right decision for some other place. Some people may learn this by
rote as a rule
to always use a /126 or a /112 for point-to-point links, but even then
it is best to
understand why.

--Michael Dillon

Re: ISP customer assignments

[Matthew Petach]

On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris  wrote:

> How many addresses do you like on point-to-point circuits?
>
> Scott
>
>
I allocate a /64, but currently I configure only a /127 subnet on the
actual interface.  That prevents the neighbor table explosion/NS/ND
traffic flooding challenges that can occur otherwise if you configure
the link as a /64, and some not-nice person decides to start ping
sweeping or nmapping the subnet; your router has to send out NS
messages for every address in the /64 being probed, update the
neighbor table with the incomplete entry, then flush it out when
no ND message is seen.  On a point-to-point link between
routers you're never going to run stateless autoconfiguration,
so there's not much downside to configuring it as a /127.

Still...just in case, I do allocate the whole /64 for the link, so
that if in the future it turns out that for some reason it really,
*really* does have to be a /64 configured on it, I can make the
change just by adjusting masks on each end, rather than
having to actually renumber the entire network.

*shrug*  As always, your mileage will vary, but this has
worked out well for me so far.

Matt

Re: ISP customer assignments

[Michael Dillon]

> He didn't really give much of a reason for the /127s yet.  I think it's
> coming up in a later session.  I think it basically boiled down to whether
> or not the customer would actually use anything bigger.  I'll write back
> when we get into that discussion.

As a service provider, you do not have any control over the customer's
environment.
As a starter, that means sticking to the /64 per subnet boundary because you
don't really know whether a customer might need some devices which assume
EUI-64 interface addressing.

But when you look at the source of your addresses, the RIRs, you will see that
there policy allows for a /56 or a /48 to be assigned to residential customers,
your choice. So, why would you want to use longer prefixes?

Admittedly, in an enterprise environment where you have total control over
the devices on the network, it may be reasonable to use /127s and other
odd prefix lengths. But only if you actually have a reason. Not wasting
addresses is not a reason, and any IPv6 architectural decisions driven by
not wasting addresses, are not reasonable decisions. It is fundamental to
IPv6 to use large address blocks that can never possibly be used up,
in order to design a network where your design decisions are based
on solid technical reasoning, and that design can remain unchanged even
if you massively scale up the number of devices on your network.

--Michael Dillon

Re: ISP customer assignments

[Joe Abley]

On 2009-10-13, at 08:05, Scott Morris wrote:


While I may agree that teaching classful routing is stupid, the
addressing part lets people start getting the concept of binary.


That's true of classless addressing, too. When students have problems  
with non-octet bit boundaries, that just means you start with mask  
lengths that are multiples of 8.



While
I'd love to think that people coming out of the school system have a
grasp of simple mathematical skills, more and more I'm finding that's
not the case.I wouldn't spend a LOT of time with it, and I  
certainly

wouldn't LEAVE at classful addressing, but it's a foundational step.

Why is the presumption faulty?


You were suggesting that classful addressing is reasonable to teach  
because it's simpler. It's not simpler, and in a modern-day context  
it's just wrong.



Joe

Re: ISP customer assignments

[Justin Shore]

George Michaelson wrote:
As a point of view on this, a member of staff from APNIC was doing a 
Masters of IT in the last 3-4 years, and had classfull A/B/C addressing 
taught to her in the networks unit. She found it quite a struggle to 
convince the lecturer that reality had moved on and they had no idea 
about CIDR.


I'm ok with teaching it to beginners to explain where we came from but 
that should be it.  It should be made excruciatingly clear in the 
training that it's no longer done that way because we found a MUCH 
better way of doing things.  That said I still occasionally refer to 
networks in classful terms and I can think of several network engineers 
who have years of enterprise experience that still don't understand CIDR.


Justin

Re: ISP customer assignments

[John Kristoff]

On Tue, 13 Oct 2009 08:14:59 -0400
Joe Abley  wrote:

> > While I may agree that teaching classful routing is stupid, the
> > addressing part lets people start getting the concept of binary.
> 
> That's true of classless addressing, too. When students have
> problems with non-octet bit boundaries, that just means you start
[...]
> You were suggesting that classful addressing is reasonable to teach  
> because it's simpler. It's not simpler, and in a modern-day context  
> it's just wrong.

I occasionally teach college level courses in networking, typically
undergrads or grad students at DePaul University.  I think I can offer
some perspective from both the academic and operator viewpoint.

No matter the class or the student, I always have to spend at least a
week on IP addressing, even to students who should be coming in with
already having had it, sometimes in multiple previous classes. Some
know it fairly well, but with holes mostly due to lack of practical
experience.  I don't think I've seen anyone who would be considered
expert enough to withstand the scrutiny of this crowd (though that
probably goes for just about anyone really :-).

No question about it, but something more than basic classful addressing
for students who don't typically have to do it on a regular basis is
not easy.  Those who aren't afraid of math, can grasp numbering systems
and binary arithmetic usually fare better.

Some instructors are most certainly doing some harm.  From what I can
tell, classful addressing is always taught and if classless is taught,
its practical reality and importance is not always stressed.  In my most
recent class this semester I made it abundantly clear to my students
that classful addressing, while interesting and useful to know from a
historic perspective, is obsolete and deprecated.  A student who has
another networking related class with another instructor came back
saying their other instructor disagrees. :/

John

Re: ISP customer assignments

[Dan White]

On 12/10/09 21:34 -0500, Justin Shore wrote:
To go along with Dan's query from above, what are the preferred methods  
that other SPs are using to deploy IPv6 with non-IPv6-capable edge  
hardware?  We too have a very limited number of dialup customers and  
will never sink another dollar in the product.  Unfortunately I also  
have brand-new ADSL2+ hardware that doesn't support IPv6 and according  
to the vendors (Pannaway) never will. 


I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix
of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda
in the same boat, but we expect to be able to gracefully transition to dual
stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring
the modems into bridged mode and leaving the layer 3 up to the customer's
router.

We're also in the process of budgeting for a new broadband aggregation
router next year that will handle IPv6. 


Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet
QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or
Cisco.

--
Dan White

Re: ISP customer assignments

[Chris Hills]

On 13/10/09 15:33, Justin Shore wrote:

He didn't really give much of a reason for the /127s yet. I think it's
coming up in a later session. I think it basically boiled down to
whether or not the customer would actually use anything bigger. I'll
write back when we get into that discussion.


Anything other than /64 removes the possibility of using privacy (aka 
temporary) addresses, enabled on Vista and above by default 
(net.ipv6.conf.all.use_tempaddr on Linux). For a single prefix a host 
may have by default up to 8 global unicast addresses - 1 EUI-64 and 7 
privacy.

Re: ISP customer assignments

[Justin Shore]

Doug Barton wrote:
Out of curiosity who is conducting this class and what was their 
rationale for using /127s?


It's a GK class.  The instructor seems to be fairly knowledgeable and 
has a lengthy history consulting on and deploying IPv6.  The class seems 
to be geared much more towards enterprise though instead of service 
providers.  That's very unfortunate considering that every one of the 15 
people in this class either works for or contracts to a SP.  Still the 
instructor has some SP knowledge so he fills in the blanks when 
possible.  We're all thinking like SPs though and we ask the SP-oriented 
questions which usually helps us steer the course the direction we want. 
 I wish GK and other training companies would start offering classes 
geared towards SPs.  They could easily take the existing courseware, add 
a couple days at the end and interject useful SP info into the earlier 
days.  All that extra info could be specifically aimed at SPs.


He didn't really give much of a reason for the /127s yet.  I think it's 
coming up in a later session.  I think it basically boiled down to 
whether or not the customer would actually use anything bigger.  I'll 
write back when we get into that discussion.


Justin

Re: ISP customer assignments

[Valdis . Kletnieks]

On Tue, 13 Oct 2009 07:39:46 EDT, Scott Morris said:
> No idea, I haven't looked at that stuff in a while.   But I would assume
> so, as it's easier to build a foundation than jumping straight to
> something difficult?

Unfortunately, classful addressing is a foundation for networking the same way
Roman numerals were a foundation for arithmetic. Both are "the way we used
to do it", neither is relevant anymore, and once learned, both are bad habits
that actively inhibit learning the more useful methods...

And yes, as a matter of fact, I *did* start learning calculus in grade school.
Have to admit that partial derivatives stumped me until middle school, though.




pgpVX8PuwxRdX.pgp
Description: PGP signature

Re: ISP customer assignments

[TJ]

Heh - Every time I try to say something close to "don't ever use this" or
"not really used anymore" WRT RIP I get a student or three that is using it,
and in fact it is there only option due to certain vendors' choices of what
routing protocols to support on certain classes of gear.

/TJ ... really hoping those certain vendors choose OSPFv3 (or ISIS, I really
don't care - anything instead of RIPng  :P  ) for IPv6.



On Tue, Oct 13, 2009 at 7:53 AM, Joe Abley  wrote:

>
> On 2009-10-13, at 07:39, Scott Morris wrote:
>
> No idea, I haven't looked at that stuff in a while.   But I would assume
>> so, as it's easier to build a foundation than jumping straight to
>> something difficult?
>>
>
> I've found RIP to be a reasonable way to teach the concept of a routing
> protocol, since the protocol is very simple and you can always close with
> "don't ever use this".
>
> But teaching classful routing and addressing is just moronic. It's a
> foundation that nothing is built on any more, and makes no sense to teach
> outside of a history class.
>
> Or did you learn calculus in grade school?  Just askin'   ;)
>>
>
> Yes, since you asked, but your presumption is faulty.
>
>
> Joe
>
>
>


-- 
/TJ

Re: ISP customer assignments

[Scott Morris]

Ok, fair enough.  I was working on the presumption not so much that it
was simpler but more than it provided a logical structure.  Having some
framework to start with provides a base.

True that binary is binary is binary...  But rather than just an
amorphous collection of x-number of bits, there's some initial rhyme and
reason.  Explaining that, getting buy in, and understanding the
limitations therein will make the next progression to VLSM simpler to grasp.

At least in my opinion.  :)

Scott

Joe Abley wrote:
>
> On 2009-10-13, at 08:05, Scott Morris wrote:
>
>> While I may agree that teaching classful routing is stupid, the
>> addressing part lets people start getting the concept of binary.
>
> That's true of classless addressing, too. When students have problems
> with non-octet bit boundaries, that just means you start with mask
> lengths that are multiples of 8.
>
>> While
>> I'd love to think that people coming out of the school system have a
>> grasp of simple mathematical skills, more and more I'm finding that's
>> not the case.I wouldn't spend a LOT of time with it, and I certainly
>> wouldn't LEAVE at classful addressing, but it's a foundational step.
>>
>> Why is the presumption faulty?
>
> You were suggesting that classful addressing is reasonable to teach
> because it's simpler. It's not simpler, and in a modern-day context
> it's just wrong.
>
>
> Joe
>

Re: ISP customer assignments

[Scott Morris]

While I may agree that teaching classful routing is stupid, the
addressing part lets people start getting the concept of binary.  While
I'd love to think that people coming out of the school system have a
grasp of simple mathematical skills, more and more I'm finding that's
not the case.I wouldn't spend a LOT of time with it, and I certainly
wouldn't LEAVE at classful addressing, but it's a foundational step.

Why is the presumption faulty?  If you did calculus, more power to you. 
However, you still needed a foundation before a pseudo-random collection
of letters and numbers together would make any sense. ;)

I learned long ago that not everyone can learn in the same fashion that
I do.  So there's a path to everything with foundations.  Some people
have a hard time subnetting IPv4 on varying boundaries.  More people
have a hard time subnetting IPv6 on varying boundaries.   While I don't
have a problem with either I have to find ways to "fix" those that do
while teaching.  And typically it's missing foundation skills.

But anyway, I don't think that's the important part!  My point was more
about not assuming that just because someone is teaching that they don't
have a realistic set of experiences to go with it as the poster from
APNIC pointed out.

Just my two cents,

Scott


Joe Abley wrote:
>
> On 2009-10-13, at 07:39, Scott Morris wrote:
>
>> No idea, I haven't looked at that stuff in a while.   But I would assume
>> so, as it's easier to build a foundation than jumping straight to
>> something difficult?
>
> I've found RIP to be a reasonable way to teach the concept of a
> routing protocol, since the protocol is very simple and you can always
> close with "don't ever use this".
>
> But teaching classful routing and addressing is just moronic. It's a
> foundation that nothing is built on any more, and makes no sense to
> teach outside of a history class.
>
>> Or did you learn calculus in grade school?  Just askin'   ;)
>
> Yes, since you asked, but your presumption is faulty.
>
>
> Joe
>
>

Re: ISP customer assignments

[Joe Abley]

On 2009-10-13, at 07:39, Scott Morris wrote:

No idea, I haven't looked at that stuff in a while.   But I would  
assume

so, as it's easier to build a foundation than jumping straight to
something difficult?


I've found RIP to be a reasonable way to teach the concept of a  
routing protocol, since the protocol is very simple and you can always  
close with "don't ever use this".


But teaching classful routing and addressing is just moronic. It's a  
foundation that nothing is built on any more, and makes no sense to  
teach outside of a history class.



Or did you learn calculus in grade school?  Just askin'   ;)


Yes, since you asked, but your presumption is faulty.


Joe

Re: ISP customer assignments

[Scott Morris]

No idea, I haven't looked at that stuff in a while.   But I would assume
so, as it's easier to build a foundation than jumping straight to
something difficult?

Or did you learn calculus in grade school?  Just askin'   ;)

Scott


Mark Newton wrote:
>
> On 13/10/2009, at 2:02 PM, Scott Morris wrote:
>
>> I happen to train people at CCIE level.  I also happen to do consulting,
>> implementation, and design work.  In my training environment, there are
>> all sorts of re-thinking of what/how things are being taught even within
>> the confines of comparison to a lab environment.
>
> Does the CCNA exam still ask questions about RIP and classful addressing?
>
> Just askin' :-)
>
>   - mark
>
>
> -- 
> Mark Newton   Email: 
> new...@internode.com.au (W)
> Network Engineer  Email: 
> new...@atdot.dotat.org  (H)
> Internode Pty Ltd Desk:   +61-8-82282999
> "Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223
>
>
>
>
>
>

Re: ISP customer assignments

[Adrian Chadd]

Nathan Ward, please stand up.



Adrian

On Tue, Oct 13, 2009, TJ wrote:
> 
> -Original Message-
> From: Justin
> To go along with Dan's query from above, what are the preferred methods 
> that other SPs are using to deploy IPv6 with non-IPv6-capable edge 
> hardware?  We too have a very limited number of dialup customers and 
> will never sink another dollar in the product.  Unfortunately I also 
> have brand-new ADSL2+ hardware that doesn't support IPv6 and according 
> to the vendors (Pannaway) never will.  We also have CMTSs that don't 
> support IPv6, even though they too are brand-new.  Those CMTSs top out 
> at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs 
> regardless of the underlying CM's IPv6 support or lack thereof (like 
> Cisco allowed for example).  Are providers implementing tunneling 
> solutions?  Pros/cons of the various solutions?
> 
> 
> > My first (potentially ignorant) response would be to get your acquisitions
> 
> > people aligned with your business, and by that I mean they should be
> making
> > a concerted effort to only buy IPv6 capable gear, especially when IPv6 is
> 
> > coming to you within that gears lifecycle.
> > I guess your customers will need to tunnel, as long as you give them a
> public
> > IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is
> better.
> 
> 

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -

RE: ISP customer assignments

[TJ]

-Original Message-
From: Justin
To go along with Dan's query from above, what are the preferred methods 
that other SPs are using to deploy IPv6 with non-IPv6-capable edge 
hardware?  We too have a very limited number of dialup customers and 
will never sink another dollar in the product.  Unfortunately I also 
have brand-new ADSL2+ hardware that doesn't support IPv6 and according 
to the vendors (Pannaway) never will.  We also have CMTSs that don't 
support IPv6, even though they too are brand-new.  Those CMTSs top out 
at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs 
regardless of the underlying CM's IPv6 support or lack thereof (like 
Cisco allowed for example).  Are providers implementing tunneling 
solutions?  Pros/cons of the various solutions?


> My first (potentially ignorant) response would be to get your acquisitions

> people aligned with your business, and by that I mean they should be
making
> a concerted effort to only buy IPv6 capable gear, especially when IPv6 is

> coming to you within that gears lifecycle.
> I guess your customers will need to tunnel, as long as you give them a
public
> IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is
better.

Re: ISP customer assignments

[Mark Smith]

On Mon, 12 Oct 2009 23:32:23 -0400
Scott Morris  wrote:

> I'm going to have to pull the "mixed-hat" on this one.  If you are
> comparing this to a true "academia" environment, I'd agree with you. 
> Too much theory, not enough reality in things.  However, I've yet to see
> the part about where the person is being trained from.
> 
> I happen to train people at CCIE level.  I also happen to do consulting,
> implementation, and design work.  In my training environment, there are
> all sorts of re-thinking of what/how things are being taught even within
> the confines of comparison to a lab environment.  But that's a personal
> point of view trying to keep reality involved and be worthwhile.
> 
> I'm not trying to open any sort of debate or can of worms here, but just
> because one is receiving training does not mean the instructor has no
> functional knowledge of something.   I'm interested in hearing the
> playout on this one as well.
> 
> How many addresses do you like on point-to-point circuits?
> 

How ever many the protocol designers thought there should be. 



> Scott
> 
> 
> 
> George Michaelson wrote:
> >
> > On 13/10/2009, at 12:54 PM, Doug Barton wrote:
> >
> >> On Oct 12, 2009, at 7:34 PM, Justin Shore 
> >> wrote:
> >>> I'm actually taking an IPv6 class right now and the topic of
> >>> customer assignments came up today (day 1).  The instructor was
> >>> suggesting dynamically allocating /127s to residential customers.  I
> >>> relayed the gist of this thread to him (/48, /56 and /64).  I expect
> >>> to dive deeper into this in the following days in the class.
> >>
> >> Out of curiosity who is conducting this class and what was their
> >> rationale for using /127s?
> >>
> >> Doug
> >
> > As a point of view on this, a member of staff from APNIC was doing a
> > Masters of IT in the last 3-4 years, and had classfull A/B/C
> > addressing taught to her in the networks unit. She found it quite a
> > struggle to convince the lecturer that reality had moved on and they
> > had no idea about CIDR.
> >
> > I have from time to time, asked people in ACM and IEEE about how one
> > informs the tertiary teaching community about this kind of change. The
> > answers were not inspiring: compared to civil engineering, where
> > compliance issues and re-training by professionals is almost regulated
> > (sorry for the R- word) as a function of professional indemnity
> > insurance and status, its much more common for the syllabus to be
> > under continual review.
> >
> > -George
> >
> >
> 

Re: ISP customer assignments

[Mark Newton]

On 13/10/2009, at 2:02 PM, Scott Morris wrote:

I happen to train people at CCIE level.  I also happen to do  
consulting,
implementation, and design work.  In my training environment, there  
are
all sorts of re-thinking of what/how things are being taught even  
within

the confines of comparison to a lab environment.


Does the CCNA exam still ask questions about RIP and classful  
addressing?


Just askin' :-)

  - mark


--
Mark Newton   Email:  new...@internode.com.au 
 (W)
Network Engineer  Email:   
new...@atdot.dotat.org  (H)

Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: ISP customer assignments

[Scott Morris]

I'm going to have to pull the "mixed-hat" on this one.  If you are
comparing this to a true "academia" environment, I'd agree with you. 
Too much theory, not enough reality in things.  However, I've yet to see
the part about where the person is being trained from.

I happen to train people at CCIE level.  I also happen to do consulting,
implementation, and design work.  In my training environment, there are
all sorts of re-thinking of what/how things are being taught even within
the confines of comparison to a lab environment.  But that's a personal
point of view trying to keep reality involved and be worthwhile.

I'm not trying to open any sort of debate or can of worms here, but just
because one is receiving training does not mean the instructor has no
functional knowledge of something.   I'm interested in hearing the
playout on this one as well.

How many addresses do you like on point-to-point circuits?

Scott



George Michaelson wrote:
>
> On 13/10/2009, at 12:54 PM, Doug Barton wrote:
>
>> On Oct 12, 2009, at 7:34 PM, Justin Shore 
>> wrote:
>>> I'm actually taking an IPv6 class right now and the topic of
>>> customer assignments came up today (day 1).  The instructor was
>>> suggesting dynamically allocating /127s to residential customers.  I
>>> relayed the gist of this thread to him (/48, /56 and /64).  I expect
>>> to dive deeper into this in the following days in the class.
>>
>> Out of curiosity who is conducting this class and what was their
>> rationale for using /127s?
>>
>> Doug
>
> As a point of view on this, a member of staff from APNIC was doing a
> Masters of IT in the last 3-4 years, and had classfull A/B/C
> addressing taught to her in the networks unit. She found it quite a
> struggle to convince the lecturer that reality had moved on and they
> had no idea about CIDR.
>
> I have from time to time, asked people in ACM and IEEE about how one
> informs the tertiary teaching community about this kind of change. The
> answers were not inspiring: compared to civil engineering, where
> compliance issues and re-training by professionals is almost regulated
> (sorry for the R- word) as a function of professional indemnity
> insurance and status, its much more common for the syllabus to be
> under continual review.
>
> -George
>
>

Re: ISP customer assignments

[George Michaelson]

On 13/10/2009, at 12:54 PM, Doug Barton wrote:

On Oct 12, 2009, at 7:34 PM, Justin Shore   
wrote:
I'm actually taking an IPv6 class right now and the topic of  
customer assignments came up today (day 1).  The instructor was  
suggesting dynamically allocating /127s to residential customers.   
I relayed the gist of this thread to him (/48, /56 and /64).  I  
expect to dive deeper into this in the following days in the class.


Out of curiosity who is conducting this class and what was their  
rationale for using /127s?


Doug


As a point of view on this, a member of staff from APNIC was doing a  
Masters of IT in the last 3-4 years, and had classfull A/B/C  
addressing taught to her in the networks unit. She found it quite a  
struggle to convince the lecturer that reality had moved on and they  
had no idea about CIDR.


I have from time to time, asked people in ACM and IEEE about how one  
informs the tertiary teaching community about this kind of change. The  
answers were not inspiring: compared to civil engineering, where  
compliance issues and re-training by professionals is almost regulated  
(sorry for the R- word) as a function of professional indemnity  
insurance and status, its much more common for the syllabus to be  
under continual review.


-George

Re: ISP customer assignments

[Doug Barton]

On Oct 12, 2009, at 7:34 PM, Justin Shore   
wrote:
I'm actually taking an IPv6 class right now and the topic of  
customer assignments came up today (day 1).  The instructor was  
suggesting dynamically allocating /127s to residential customers.  I  
relayed the gist of this thread to him (/48, /56 and /64).  I expect  
to dive deeper into this in the following days in the class.


Out of curiosity who is conducting this class and what was their  
rationale for using /127s?


Doug 

Re: ISP customer assignments

[Justin Shore]

Dan White wrote:

How are other providers approaching dial-up? I would presume we are in the
same boat as a lot of other folks - we have aging dial-up equipment that
does not support IPv6 (3com Total Control). Our customer base has dropped
quite a bit, and we have even kicked around the idea dropping that service
and forcing customers to purchase broadband service or go elsewhere.

What are other providers doing, or considering doing?


I'd like to beat this dead horse some more if you gents don't mind.  I 
think there's still some life left in the beast before we haul it off to 
the glue factory.


I'm actually taking an IPv6 class right now and the topic of customer 
assignments came up today (day 1).  The instructor was suggesting 
dynamically allocating /127s to residential customers.  I relayed the 
gist of this thread to him (/48, /56 and /64).  I expect to dive deeper 
into this in the following days in the class.


What are providers doing for residential customers and how does it 
different from business customers?  At what point are you assigning 
bigger blocks?


To go along with Dan's query from above, what are the preferred methods 
that other SPs are using to deploy IPv6 with non-IPv6-capable edge 
hardware?  We too have a very limited number of dialup customers and 
will never sink another dollar in the product.  Unfortunately I also 
have brand-new ADSL2+ hardware that doesn't support IPv6 and according 
to the vendors (Pannaway) never will.  We also have CMTSs that don't 
support IPv6, even though they too are brand-new.  Those CMTSs top out 
at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs 
regardless of the underlying CM's IPv6 support or lack thereof (like 
Cisco allowed for example).  Are providers implementing tunneling 
solutions?  Pros/cons of the various solutions?


Thanks
 Justin

Re: ISP customer assignments

[Michael Dillon]

> How are other providers approaching dial-up? I would presume we are in the
> same boat as a lot of other folks - we have aging dial-up equipment that
> does not support IPv6 (3com Total Control). Our customer base has dropped
> quite a bit, and we have even kicked around the idea dropping that service
> and forcing customers to purchase broadband service or go elsewhere.

Separate these technical issues from IPv6 allocation plans. If you intend to
continue running an ISP in two years from now, either make a simple plan
and allocate a /48 to every customer site, whether or not they are currently
taking an IPv6 service from you. Or, take the slightly more complex plan
and allocate a /56 per site where it is known for sure, 100% that the site
is a private residence. If it is not, or there is doubt, then allocate a /48.

> I expect we won't invest any more into dial-up equipment, and when a
> dial-up customer happens to ask about IPv6 (if ever), we'll strongly
> encourage them to move to broadband, and as a last resort manually
> configure a /64 tunnel to them.

You might use up a /64 for the two tunnel endpoints, but be sure to allocate
the customer at least a /56.

> What are other providers doing, or considering doing?

In general, big providers are not going to attempt to cope with any older
equipment that does not fully support IPv6. But small providers will be
rather innovative and try things like your tunnel suggestion. After all,
if Hurricane Electric can run an IPv6 tunnel broker, why can't you?

--Michael Dillon

Re: ISP customer assignments

[Dan White]

On 08/10/09 11:46 +0100, Michael Dillon wrote:

There seems to be a variance between "It's OK to just give out a /64" to
"You better be thinking about giving out a /48". I can live in those
boundaries and am most likely fine with either. I'm leaning toward a /56
for regular subscribers and a /48 only for business or large scale
customers, and undecided on dial-up. How does this sound?


The starting point is to give everybody a /48 per site. If a business customer
has 3 sites, then give them enough space for a /48 for each site. Could be
3 /48s or could be a /46.


How are other providers approaching dial-up? I would presume we are in the
same boat as a lot of other folks - we have aging dial-up equipment that
does not support IPv6 (3com Total Control). Our customer base has dropped
quite a bit, and we have even kicked around the idea dropping that service
and forcing customers to purchase broadband service or go elsewhere.

I expect we won't invest any more into dial-up equipment, and when a
dial-up customer happens to ask about IPv6 (if ever), we'll strongly
encourage them to move to broadband, and as a last resort manually
configure a /64 tunnel to them.

What are other providers doing, or considering doing?

--
Dan White
BTC Broadband

Re: ISP customer assignments

[Michael Dillon]

> Sorry to be a curmudgeon and let me play devil's advocate for a minute.  I
> realize that the address space is enormous; gigantic, even, but if we treat
> it as cavalierly as you all are proposing, it will get used up.  If its
> treated like an infinite resource  that will never, ever be used up as we
> have done with every other resource on the planet, won't we find ourselves
> in a heap of trouble?

Of course, you are right.

That's why, when some people took a close look at the numbers based on
a /48 per site, and published their findings, the RIRs made an adjustment to
address allocation policy so that it was acceptable to allocate a /56 for a
consumer customer, i.e. private residence of some sort. By doing that, they
calculated that they could mitigate the small risk that we would run very low
on IPv6 addresses around 100 years from now. Having made the change, we
are now confident that there are plenty of IPv6 addresses to last more than
a century, which basically means that you and your children and your grand
children will all be dead when IPv6 gets close to exhaustion.

Geoff Huston wrote this: 
to explain the small risk, and his proposals to adjust the HD ratio and go to
a /56 for private residential assignments was basically accepted. If only a few
of the biggest cable ISPs use the /56 model, then we are OK.

I have great confidence that our descendants will avoid the Idiocracy and
be capable of designing and deploying a replacement for IPv6 if that is ever
needed.  Last time I checked, my
taps were still delivering fresh clean "toilet water", not Brawndo energy drink.

--Michael Dillon

Re: ISP customer assignments

[TJ]

And I will play devil's advocate to the devil's advocate ... wait, does that
make me God's advocate?  Nice!


On Thu, Oct 8, 2009 at 10:24 AM, Curtis Maurand  wrote:

>
> Sorry to be a curmudgeon and let me play devil's advocate for a minute.  I
> realize that the address space is enormous; gigantic, even, but if we treat
> it as cavalierly as you all are proposing, it will get used up.  If its
> treated like an infinite resource  that will never, ever be used up as we
> have done with every other resource on the planet, won't we find ourselves
> in a heap of trouble?
> Curtis



But the thing is - no-one is proposing we treat it as infinite - just that
we treat it the way it was designed to be used.

The IETF community "did the math" and decided a /48 per customer was both
scalable and sufficient.

The community, by and in large, decided that /56s were more appropriate for
"small customers" and that is fine, even if some still view it as
additional, unneeded complexity.

My opinion, based on having done the math as well and operational experience
to date, seems to jive that /48s (or even moreso /56s) will work.  So let's
get to it!



/TJ

Re: ISP customer assignments

[Tim Chown]

On Thu, Oct 08, 2009 at 10:24:30AM -0400, Curtis Maurand wrote:
> 
> Sorry to be a curmudgeon and let me play devil's advocate for a minute.  
> I realize that the address space is enormous; gigantic, even, but if we 
> treat it as cavalierly as you all are proposing, it will get used up.  
> If its treated like an infinite resource  that will never, ever be used 
> up as we have done with every other resource on the planet, won't we 
> find ourselves in a heap of trouble? 

At this stage we're only 'being cavalier' with 1/8th of the space.

We can be more restrictive with the the other 7/8ths if those predicting
rapid consumption turn out to be correct.

Right now that would be a nice problem to have.

Tim

Re: ISP customer assignments

[Curtis Maurand]

Sorry to be a curmudgeon and let me play devil's advocate for a minute.  
I realize that the address space is enormous; gigantic, even, but if we 
treat it as cavalierly as you all are proposing, it will get used up.  
If its treated like an infinite resource  that will never, ever be used 
up as we have done with every other resource on the planet, won't we 
find ourselves in a heap of trouble? 


Curtis

Michael Dillon wrote:

There seems to be a variance between "It's OK to just give out a /64" to
"You better be thinking about giving out a /48". I can live in those
boundaries and am most likely fine with either. I'm leaning toward a /56
for regular subscribers and a /48 only for business or large scale
customers, and undecided on dial-up. How does this sound?



The starting point is to give everybody a /48 per site. If a business customer
has 3 sites, then give them enough space for a /48 for each site. Could be
3 /48s or could be a /46.

But, if you have a lot of residential customers, it is quite
reasonable to give them
a /56 per site instead. Be prepared for some customers to ask for two
/56s because
they have a granny-flat or in-law apartment in the house. Also be
prepared for some
to ask for a /48 because they are running a business at home, or they
are technical
types who have a their own home network lab.

Your plan for /56 to residential subscribers and /48 to business
subscribers sounds
perfectly fine as long as your systems have some way to accomodate
that grey area,
either by recording a /48 against a residential subscriber or counting
them as a class
of business customer that pays a residential rate.

Charging a customer extra for more IPv6 addresses just will not fly in
a competitive
market.

--Michael Dillon

  

Re: ISP customer assignments

[Michael Dillon]

> There seems to be a variance between "It's OK to just give out a /64" to
> "You better be thinking about giving out a /48". I can live in those
> boundaries and am most likely fine with either. I'm leaning toward a /56
> for regular subscribers and a /48 only for business or large scale
> customers, and undecided on dial-up. How does this sound?

The starting point is to give everybody a /48 per site. If a business customer
has 3 sites, then give them enough space for a /48 for each site. Could be
3 /48s or could be a /46.

But, if you have a lot of residential customers, it is quite
reasonable to give them
a /56 per site instead. Be prepared for some customers to ask for two
/56s because
they have a granny-flat or in-law apartment in the house. Also be
prepared for some
to ask for a /48 because they are running a business at home, or they
are technical
types who have a their own home network lab.

Your plan for /56 to residential subscribers and /48 to business
subscribers sounds
perfectly fine as long as your systems have some way to accomodate
that grey area,
either by recording a /48 against a residential subscriber or counting
them as a class
of business customer that pays a residential rate.

Charging a customer extra for more IPv6 addresses just will not fly in
a competitive
market.

--Michael Dillon

Re: ISP customer assignments

[Michael Dillon]

> I would disagree. IPv6 is designed around class boundaries which, in my
> understanding, are:
>
> A layer two network gets assigned a /64
> A customer gets assigned a /48

A "site" gets assigned a /48. It could be a customer site, or one of
your many sites
or one of a customer's many sites. I interpret "site" to roughly be
within a single
building, although a campus type arrangement could be considered a single
site if the network architects want to do it that way.

> An ISP gets assigned a /32 (unless they need more)

> If your complaint is that all devices in a /64 are going to see IPv6
> broadcast/multicast packets from the rest of the devices in that subnet,
> then don't assign 2^64 devices to that subnet.

Indeed!

> I still don't understand why its infuriating to you, but I can certainly
> tell that it is.

It's purely a case of stage 2  which is a good thing IMHO, since it
shows some movement forwards past denial.

Confronting the Reality of Emotional Denial and Grief


BTW, that PDF really *is* about IPv6 deployment.

--Michael Dillon

Re: ISP customer assignments

[Ricky Beam]

On Tue, 06 Oct 2009 17:40:40 -0400, Mark Smith  
 wrote:

I think it is both "classless" and "classfull" (although it's different
enough that we probably should stop using loaded IPv4 terms ...)


It's _classless_.  There's none of this Class A, B, C, D, or E nonsense.   
The word everyone is dancing around is, "hierarchical".  How the bits get  
divided up depends on what you want to do with it.  SLAAC, in it's current  
form, requires a 64-bit prefix, but there are other ways to assign  
addresses that do not have that requirement.


--Ricky

Re: ISP customer assignments

[James Hess]

>>  unimaginably huge *classless* network.  Yet, 2 hours into day one, a
>>  classful boundary has already been woven into it's DNA.  Saying it's

No bit patterns in a V6 address indicate total size of a network. v6
doesn't bring classful addressing back or get rid of CIDR..
v6 dispenses with something much older:  common use  of VLSM on the
local LAN  and sizing subnets  based on the number of hosts.

Instead a form of FLSM is recommended, a fixed standard subnet size of  /64
that essentially all IPv6 networks use for the subnets that have hosts on them.
This restores consistency to LAN addressing.

In  V4 there is a valid reason for choosing VLSM and sizing every
subnet:   IP addresses are scarce.  V6  removes that scarcity problem.

No more   unanticipated growth  necessitating an addressing re-design,
or at least error-prone  adjustment of netmasks on all hosts.
No more   hodgepodge  of different   netmask settings  for different sized LANs.
No more LAN  address ranges   starting or ending with a different
trailing string of digits  than other LANs.


 /64   is the standard.
V6 leaves the operator able to pick something different,  but in most cases it
would be a very poor design practice,  and ISPs should think long and
hard before ignoring the standard and trying to issue a customer
subnet a  /128,   instead of /48 or /56.

However...  none of the network protocol documents were  ever able to
prevent determined people from coming up with bad designs,   or
ignoring recommendations due to politics or preconceived notion(s);
don't hold your breath on that one...


--
-J

Re: ISP customer assignments

[Mark Smith]

On Tue, 6 Oct 2009 09:25:44 -0500
Dan White  wrote:

> On 05/10/09 23:23 -0400, Ricky Beam wrote:
> > You underestimate the power of the marketing department and the bean  
> > counters.  I assure you, residential ISPs are looking for schemes to give 
> > out as little address space as possible.
> 
> That has not been my (limited) experience. If you are aware of any ISPs
> which are not handing out a reasonable address space to customers, please
> call them out.
> 

Once one of them actually realises how much address space they've been
given, and that giving more perceived value to a customer will win them
the business, I think they will e.g. same price, same quota/bandwidth,
one ISP giving you 64K more address space. I think customers will say,
"I fully understand what it's for, and I don't really know what I'll
use it for .. but I'll have it if I ever need it."

> >> The current revision of IPv6 introduces a way to nail down the boundary
> >> between network and host.  This is fantastic, from an implementation
> >> point of view.  It simplifies the design of silicon for forwarding
> >> engines, etc.
> >
> > And it's 150% Wrong Thinking(tm).  IPv6 is classless - PERIOD.  The  
> > instant some idiot wires /64 into silicon, we're right back to not being  
> > able to use x.x.x.0 and x.x.x.255.  Addresses are 128-bits; you cannot  
> > make any assumptions about what people may or may not be doing with those 
> > bits.  If I don't use SLAAC, then I'm not bound by it's lame rules.
> >

I think it is both "classless" and "classfull" (although it's different
enough that we probably should stop using loaded IPv4 terms ...)

Forwarding is purely "classless" - the best route is the one with the
longest matching prefix length, regardless of where that prefix length
lands within the 128 bits.

For 1/8th of the address space, it's "classful". It's been shown that
humans work best with simplicity, so introducing fixed operational (but
not forwarding) boundaries between node, subnet and global prefixes
makes IPv6 much more operationally simple than dealing with IPv4
classes, subnets or classless addressing. I think anybody who has dealt
operationally with IPX, Appletalk, XNS, DECnet or even Ethernet with
it's single OUI/Node ID boundary would agree.

If the plan for the "classful" 1/8th ends up being wrong, the
"classless" forwarding means that we don't have to deploy new routing
code or hardware to change to a different addressing model, be it
"classless" or something else.

> >> You don't do that.  Or at least, you shouldn't do that.  :-)  We have a
> >> fairly reliable DNS system these days...
> 
> The assumption that IPv6 addresses are harder has not been my
> experience. A server address of 2610:b8:5::1 is just as easy
> for me to remember as 67.217.144.1. Granted, auto configured
> addresses are much harder to remember.
> 
> > And where did DNS get the name/number assignments?  In my case, it's  
> > either been typed in by ME or automatically updated by DHCP.
> 
> Anything I put in DNS is a server/router, and gets a static address, just
> like with IPv4.
> 
> -- 
> Dan White
> BTC Broadband
> 

Re: ISP customer assignments

[Valdis . Kletnieks]

On Tue, 06 Oct 2009 09:34:28 PDT, Owen DeLong said:

> although that isn't the case today.  However, I believe
> that 90.1 is supposed to be parsed equivalent to 90.0.0.1
> and 90.5.1 is supposed to be treated as 90.5.0.1, so,
> 32.1.13.184.241.1 should also work for the above if
> you expanded todays IPv4 notation to accept IPv6 length
> addresses.

So if you expand the notation like that, is 32.1.13.7 a 32 bit IPv4
address, or a 128 bit IPv6 address with lots of zeros between 13 and 7?

They chose the ":" instead of overloading '.' for a *reason*...


pgpckqTyuip4k.pgp
Description: PGP signature

Re: ISP customer assignments

[Owen DeLong]

On Oct 6, 2009, at 7:29 AM, Lee Howard wrote:


-Original Message-
From: robert.e.vanor...@frb.gov [mailto:robert.e.vanor...@frb.gov]
Sent: Monday, October 05, 2009 7:41 PM
To: nanog@nanog.org
Subject: Re: ISP customer assignments

Organizations will be provided /48s or smaller, but given the current
issues with routing /48's globally, I think you will find more
organizations fighting for /32s or smaller...


Most organizations will still be assigned a /48 (or whatever) from  
their
ISP.  Provider-aggregable addressing has no routing scalability  
problems.



I can see between IPv4 and IPv6 is how much of a pain it is to type  
a 128

bit address...


I have to agree, here.  Moving between letters and numbers, and having
to hit "shift" to use the colon wastes valuable keystrokes compared to
the keypad.  However, compare IPv6 vs IPv4-like numbering:

2001:db8:f1::1  
81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1

Did I type the right number of zeroes?


I don't know, but, it's not 81.93.35.12...

It's:
32.1.13.184.241.0.0.0.0.0.0.0.0.0.0.1

And that is the correct number of zeroes for 2001:db8:f1::1.

Also, there's no reason the syntax couldn't be made

32.1.13.184.241..1

although that isn't the case today.  However, I believe
that 90.1 is supposed to be parsed equivalent to 90.0.0.1
and 90.5.1 is supposed to be treated as 90.5.0.1, so,
32.1.13.184.241.1 should also work for the above if
you expanded todays IPv4 notation to accept IPv6 length
addresses.

Owen



Lee

Re: ISP customer assignments

[Kevin Loch]

Owen DeLong wrote:


Part of the reason that 128 bits was chosen (64 bits is FAR more than
enough) was that it allowed for 64 bits of stateless auto-configuration
(IEEE was already pushing EUI-64) within each network and still
provided more than enough network numbers.


I'm sure the Really Smart People over at the IETF could have figured
out a way to do auto configuration with "just" 16 bits of /112 (or
a /48 of 64 bit space).

It will be interesting to see if things evolve to using /112's anyway
just to escape auto configuration.  I use them for router links and 
server subnets because it's a convenient boundary for notation.


- Kevin

RE: ISP customer assignments

[Brian Johnson]

Rick et al,

I work at an ISP, and I know staff at several other ISPs, we are all
trying to do this right. If a /56 makes sense and is supported by the
IPv6 technology and we won't have issues supplying these to customers
(technically speaking), then we will most likely do this or something
similar. The issue is more of a nuanced issue.

There seems to be a variance between "It's OK to just give out a /64" to
"You better be thinking about giving out a /48". I can live in those
boundaries and am most likely fine with either. I'm leaning toward a /56
for regular subscribers and a /48 only for business or large scale
customers, and undecided on dial-up. How does this sound?

This wasn't suppose to digress to this level of vitriol.

- Brian


> -Original Message-
> From: Ricky Beam [mailto:jfb...@gmail.com]
> Sent: Monday, October 05, 2009 10:23 PM
> To: Joe Greco; robert.e.vanor...@frb.gov
> Cc: nanog@nanog.org
> Subject: Re: ISP customer assignments
> 
> On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco 
> wrote:
> > Generally speaking, we shouldn't *want* end users to be provided
with
> a
> > single /64.  The number of addresses is not the point.  The idea of
> > getting rid of the horribleness that is CIDR is the point.
> 
> You underestimate the power of the marketing department and the bean
> counters.  I assure you, residential ISPs are looking for schemes to
> give
> out as little address space as possible.
> 
> > The current revision of IPv6 introduces a way to nail down the
> boundary
> > between network and host.  This is fantastic, from an implementation
> > point of view.  It simplifies the design of silicon for forwarding
> > engines, etc.
> 
> And it's 150% Wrong Thinking(tm).  IPv6 is classless - PERIOD.  The
> instant some idiot wires /64 into silicon, we're right back to not
> being
> able to use x.x.x.0 and x.x.x.255.  Addresses are 128-bits; you cannot
> make any assumptions about what people may or may not be doing with
> those
> bits.  If I don't use SLAAC, then I'm not bound by it's lame rules.
> 
> > You don't do that.  Or at least, you shouldn't do that.  :-)  We
have
> a
> > fairly reliable DNS system these days...
> 
> And where did DNS get the name/number assignments?  In my case, it's
> either been typed in by ME or automatically updated by DHCP.
> 
> --Ricky

RE: ISP customer assignments

[Lee Howard]

> -Original Message-
> From: robert.e.vanor...@frb.gov [mailto:robert.e.vanor...@frb.gov]
> Sent: Monday, October 05, 2009 7:41 PM
> To: nanog@nanog.org
> Subject: Re: ISP customer assignments
> 
> Organizations will be provided /48s or smaller, but given the current
> issues with routing /48's globally, I think you will find more
> organizations fighting for /32s or smaller... 

Most organizations will still be assigned a /48 (or whatever) from their
ISP.  Provider-aggregable addressing has no routing scalability problems.


> I can see between IPv4 and IPv6 is how much of a pain it is to type a 128
> bit address...  

I have to agree, here.  Moving between letters and numbers, and having 
to hit "shift" to use the colon wastes valuable keystrokes compared to 
the keypad.  However, compare IPv6 vs IPv4-like numbering:

2001:db8:f1::1  
81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1

Did I type the right number of zeroes?


Lee

Re: ISP customer assignments

[Dan White]

On 05/10/09 23:23 -0400, Ricky Beam wrote:
You underestimate the power of the marketing department and the bean  
counters.  I assure you, residential ISPs are looking for schemes to give 
out as little address space as possible.


That has not been my (limited) experience. If you are aware of any ISPs
which are not handing out a reasonable address space to customers, please
call them out.


The current revision of IPv6 introduces a way to nail down the boundary
between network and host.  This is fantastic, from an implementation
point of view.  It simplifies the design of silicon for forwarding
engines, etc.


And it's 150% Wrong Thinking(tm).  IPv6 is classless - PERIOD.  The  
instant some idiot wires /64 into silicon, we're right back to not being  
able to use x.x.x.0 and x.x.x.255.  Addresses are 128-bits; you cannot  
make any assumptions about what people may or may not be doing with those 
bits.  If I don't use SLAAC, then I'm not bound by it's lame rules.



You don't do that.  Or at least, you shouldn't do that.  :-)  We have a
fairly reliable DNS system these days...


The assumption that IPv6 addresses are harder has not been my
experience. A server address of 2610:b8:5::1 is just as easy
for me to remember as 67.217.144.1. Granted, auto configured
addresses are much harder to remember.

And where did DNS get the name/number assignments?  In my case, it's  
either been typed in by ME or automatically updated by DHCP.


Anything I put in DNS is a server/router, and gets a static address, just
like with IPv4.

--
Dan White
BTC Broadband

RE: ISP customer assignments

[Lee Howard]

> -Original Message-
> From: William Herrin [mailto:herrin-na...@dirtside.com]
> Sent: Monday, October 05, 2009 12:58 PM
> To: Brian Johnson
> Cc: nanog@nanog.org
> Subject: Re: ISP customer assignments
> 
> /60 - the smallest amount you should allocate to a downstream customer
> with more than one computer. Anything smaller will cost you extra
> management overhead from not matching the nibble boundary for RDNS
> delegation, 

I have a lack of imagination, I guess.  I can't imagine anyone larger than
a small residential user being assigned a /60 or less.  Therefore, 
nybble boundary for rDNS delegation only matters if you delegate
rDNS for that block.  

> handling multiple routes when the customer grows, not

Any customer getting a /60 or less will be dynamically numbered
(RA, DHCPv6, whatever), and if more space is needed, should be
easily renumbered into a larger prefix.

> matching the standard /64 subnet size and a myriad other obscure
> issues.

I don't know about "myriad" but I agree that /64 is the standard 
subnet size.

I am *not* advocating assignments of /60 or less, just pointing
out that if you do it, it doesn't have to break.

Lee

Re: ISP customer assignments

[TJ]

Actually, I would argue IPv6 is a bit of both classfull and classless.
(Moreso the latter ...)

The protocol itself, /64 "mandate" aside, certainly allows you to place
arbitrary-bit-long prefix lengths - and to aggregate/summarize at any
point.  And /64s do not so much apply in some cases, whether 'permitted' by
spec (/128) or not(/126).  Thus classless.

OTOH, we have policies that define how we will allocate this address space
that do look eerily similar to the Classfull methods we started off with in
IPv4.

I too am always ... hmm, surprised isn't the right word ... when this
angers|scares|confuses people.


Anyway, I enjoy the conversation and hope this helps ...
/TJ


On Tue, Oct 6, 2009 at 9:36 AM, Dan White  wrote:

> On 05/10/09 22:28 -0400, Ricky Beam wrote:
>
>> On Mon, 05 Oct 2009 17:13:37 -0400, Dan White  wrote:
>>
>>> I don't understand. You're saying you have overlapping class boundaries
>>> in your network?
>>>
>>
>> No.  What I'm saying is IPv6 is supposed to be the new, ground-breaking,
>>  unimaginably huge *classless* network.  Yet, 2 hours into day one, a
>>  classful boundary has already been woven into it's DNA.  Saying it's
>>
>
> I would disagree. IPv6 is designed around class boundaries which, in my
> understanding, are:
>
> A layer two network gets assigned a /64
> A customer gets assigned a /48
> An ISP gets assigned a /32 (unless they need more)
>
>  classless because routing logic doesn't care is pure bull.  In order for
>>  the most basic, fundamental, part (the magic -- holy grail -- address
>>  autoconfig) to function, the network has to be a minimum of /64.  Even
>>  when the reason for that limit -- using one's MAC to form a (supposedly)
>>  unique address without having to consult with anything or fire off a
>>  single packet -- has long bit the dust; privacy extensions generate
>>  addresses at random and have to take steps to avoid address collisions, so
>> continuing to cling to "it has to be 64bits" is infuriating.
>>
>
> IPv6 provides you the opportunity to design your network around your layer
> two needs, not limited by restrictive layer 3 subnetting needs.
>
> If your complaint is that all devices in a /64 are going to see IPv6
> broadcast/multicast packets from the rest of the devices in that subnet,
> then don't assign 2^64 devices to that subnet.
>
> I still don't understand why its infuriating to you, but I can certainly
> tell that it is.
>
> --
> Dan White
> BTC Broadband
>
>


-- 
/TJ

Re: ISP customer assignments

[Dan White]

On 05/10/09 22:53 -0400, Ricky Beam wrote:

On Mon, 05 Oct 2009 18:55:35 -0400, Dan White  wrote:

All of the items in the above list are true of DHCP. ...


In an IPv4 world (which is where DHCP lives), it's much MUCH harder to  
track assignments -- I don't share my DHCP logs with anyone, nor does  
anyone send theirs to me.  From the perspective of remote systems (ie. 
not on the same network), there is about a 100% chance NAT is involved 
making it near impossible to individually identify a specific machine, 
even if it gets the same address every Tuesday when you're at Starbucks 
for coffee.  IPv6 does away with NAT (or it's supposed to); in doing so, 
the veil is removed and everything that had been hidden from site is now 
openly displayed.  If the "host" part of your address never changes, then 
you are instantly identifiable everywhere you go, with zero effort, 
forever.


Use random addresses, and change as often as you like. Why depend on
someone else's DHCP server to provide you the addressing uniqueness you
desire?

--
Dan White
BTC Broadband