Re: v6 subnet size for DSL & leased line customers

[Stephen Sprunk]

Thus spake "Simon Lyall" <[EMAIL PROTECTED]>

On Wed, 2 Jan 2008, Deepak Jain wrote:

Is there anything inherently harmful with suggesting that filtering at
RIR boundaries should be expected, but those that accept somewhat
more lenient boundaries are nice guys??? When the nice guys run
out of resources, they can filter at RIR boundaries and say they are
doing so as a security upgrade :_).


So how would this work for large companies?

In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should
only get at most a /48 from each RIR.


In what theory?  They'd get at _minimum_ a /48 from each RIR that has 
approved PIv6.  If they needed more, they merely have to fill out the 
appropriate paperwork showing justification.  If they operate in regions 
where the RIR hasn't approved PIv6, they'd route around the failure there 
and use space assigned by other RIRs.  (Not saying I approve of that, but 
it's reality.)


Currently ARIN is approving all requests for more than a /48 since there is 
no definition of what "justify" means in that context.  Ebay, which is 
hardly the size of the companies you listed, got a /41.  That obviously 
needs fixing, but the problem is the opposite of the one you seem to be 
theorizing.



How should they handle region offices, Especially mutihomed ones?


Announce their prefix from all locations, with more-specifics for TE 
purposes.  Presumably their upstreams would carry the more-specifics since 
they're being paid to, but folks further away would filter them and only see 
the covering aggregate, which is good enough.


(Note this assumes they have an internal network; if they didn't, each 
disconnected part would be a "site" and qualify for a /48 on its own. 
That's a suboptimal solution, though, for reasons too numerous to list.)


S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking 

RE: v6 subnet size for DSL & leased line customers

[Jamie Bowden]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Leo Bicknell
Sent: Thursday, December 27, 2007 8:51 AM
To: North American Network Operators Group
Subject: Re: v6 subnet size for DSL & leased line customers

In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch
van Beijnum wrote:
> 100% of the DHCP functionality). But apart from that, some of the  
> choices made along the way make DHCPv6 a lot harder to use than DHCP  
> for IPv4. Not only do you lack a default gateway (which is actually a

> good thing for fate sharing reasons) but also a subnet prefix length  
> and any extra on-link prefixes. So even if you do address  
> configuration with DHCPv6 you need RAs for that other information.  

I would note, it's not too late to fix these problems.  We don't
have wide spread IPv6 deployment yet, and I can't imagine it's all
that hard to send a default gateway in DHCPv6, for example.


--

Someone earlier threw out an offhand 'preferred gateway' DHCPv6
parameter as a possibility.  This is actually a nifty idea...

"Hey, you there, use potential gateways in the following order!"

It has the same utility and simplicity that MX records do.

Jamie

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Tue, 1 Jan 2008 12:57:17 +0100
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> 
> On 31 dec 2007, at 1:24, Mark Smith wrote:
> 
> > Another idea would be to give each non-/48 customer the
> > first /56 out of each /48.
> 
> Right, so you combine the downsides of both approaches.
> 
> It doesn't work when ARIN does it:
> 

Well, ARIN aren't running the Internet route tables. If they were, I'd
assume they'd force AS6453 to do the right thing and aggregate their
address space. 

> *  24.122.32.0/20   4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.48.0/20   4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.64.0/20   4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.80.0/20   4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.96.0/20   4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.112.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.128.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.144.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.160.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.176.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.192.0/19  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.224.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> *  24.122.240.0/20  4.68.1.166   0 0 3356 6453  
> 11290 i
> 
> And it's unlikely to work here: for those standard size blocks, you  
> really don't want any per-user config: you want those to be assigned  
> automatically. But for the /48s you do need per-user config, if only  
> that this user gets a /48. So these two block sizes can't  
> realistically come from the same (sub-) range.

Maybe I'm not understanding this correctly. Are you saying that
customers who have a /56 would get dynamic ones i.e. a different one
each time they reconnect? If they've got a routed downstream topology,
with multiple routers and subnets (because of course, they've got 256
of them), I don't think customers will be very happy about having to
renumber top /56 bits if e.g. they have a DSL line sync drop out and
get a different /56.

Static assignments of /56 to customers make sense to me, and that's the
assumption I've made when suggesting the addressing scheme I proposed.
Once you go static with /56s, you may as well make it easy for both
yourself and the customer to move to a /48 that encompasses the
original /56 (or configure the whole /48 for them from the outset).

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 31 dec 2007, at 1:24, Mark Smith wrote:


Another idea would be to give each non-/48 customer the
first /56 out of each /48.


Right, so you combine the downsides of both approaches.

It doesn't work when ARIN does it:

*  24.122.32.0/20   4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.48.0/20   4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.64.0/20   4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.80.0/20   4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.96.0/20   4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.112.0/20  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.128.0/20  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.144.0/20  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.160.0/20  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.176.0/20  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.192.0/19  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.224.0/20  4.68.1.166   0 0 3356 6453  
11290 i
*  24.122.240.0/20  4.68.1.166   0 0 3356 6453  
11290 i


And it's unlikely to work here: for those standard size blocks, you  
really don't want any per-user config: you want those to be assigned  
automatically. But for the /48s you do need per-user config, if only  
that this user gets a /48. So these two block sizes can't  
realistically come from the same (sub-) range.

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 30 dec 2007, at 21:33, Scott Weeks wrote:

I haven't requested anything yet.  That's why I came to you folks.   
To learn and then get busy on it.  Thanks for your top-down and  
bottom-up idea.  I will probably also intersperse /56s in between  
allocations as well; filling them in later if it ever gets to that.


If you know that you're going to need more than a /32, be sure to ask  
ARIN for more than the default. But these things are almost impossible  
to get right the first time, so don't sweat it if you have to come  
back for more later. There are more than 8 prefixes per AS for IPv4.  
One prefix per AS for IPv6 is a laudable goal, but it's not a huge  
deal if it's more like 2.

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Tue, 1 Jan 2008 10:27:50 +1030
Mark Smith <[EMAIL PROTECTED]> wrote:

> 
> On Mon, 31 Dec 2007 13:18:41 -0800
> Joel Jaeggli <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Mark Smith wrote:
> > 
> > > 
> > > Another idea would be to give each non-/48 customer the
> > > first /56 out of each /48. If you started out with a /30 or /31 RIR block 
> > > , by
> > > the time you run out of /48s, you can either start using up the
> > > subsequent /56s out of the first /48, as it's likely that the first /56
> > > customer out of the /48 would have needed the /48 by that time.
> > 
> > As stated, that approach has really negative implications for the number
> > of routes you carry in your IGP.
> > 
> 
> Well, for 120K+ customers, I doubt you're using an IGP for anything
> much more than BGP loopbacks - and you'd have to be aggregating routes
> at a higher layer in your routing hierarchy anyway, to cope with 120K
> routes, regardless of what method you use to dole out /48s or /56s to
> end-sites.
>

It being New Year's Day and my brain not working right yet ... you'd
probably divide your RIR block up across your PoPs, and then could use
this technique within each PoP, with the PoP being the route aggregation
boundary. 
> 
> > > Alternatively you might have become more comfortable with giving each
> > > customer a /48, and wouldn't require any of them to renumber - they'd
> > > just have to shorten their prefix length.
> > > 
> > > Regards,
> > > Mark.
> > > 
> > 
> 
> 
> -- 
> 
> "Sheep are slow and tasty, and therefore must remain constantly
>  alert."
>- Bruce Schneier, "Beyond Fear"


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Mon, 31 Dec 2007 13:18:41 -0800
Joel Jaeggli <[EMAIL PROTECTED]> wrote:

> 
> Mark Smith wrote:
> 
> > 
> > Another idea would be to give each non-/48 customer the
> > first /56 out of each /48. If you started out with a /30 or /31 RIR block , 
> > by
> > the time you run out of /48s, you can either start using up the
> > subsequent /56s out of the first /48, as it's likely that the first /56
> > customer out of the /48 would have needed the /48 by that time.
> 
> As stated, that approach has really negative implications for the number
> of routes you carry in your IGP.
> 

Well, for 120K+ customers, I doubt you're using an IGP for anything
much more than BGP loopbacks - and you'd have to be aggregating routes
at a higher layer in your routing hierarchy anyway, to cope with 120K
routes, regardless of what method you use to dole out /48s or /56s to
end-sites.


> > Alternatively you might have become more comfortable with giving each
> > customer a /48, and wouldn't require any of them to renumber - they'd
> > just have to shorten their prefix length.
> > 
> > Regards,
> > Mark.
> > 
> 


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Joel Jaeggli]

Mark Smith wrote:

> 
> Another idea would be to give each non-/48 customer the
> first /56 out of each /48. If you started out with a /30 or /31 RIR block , by
> the time you run out of /48s, you can either start using up the
> subsequent /56s out of the first /48, as it's likely that the first /56
> customer out of the /48 would have needed the /48 by that time.

As stated, that approach has really negative implications for the number
of routes you carry in your IGP.

> Alternatively you might have become more comfortable with giving each
> customer a /48, and wouldn't require any of them to renumber - they'd
> just have to shorten their prefix length.
> 
> Regards,
> Mark.
> 

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sun, 30 Dec 2007 12:08:34 +0100
Jeroen Massar <[EMAIL PROTECTED]> wrote:

> Scott Weeks wrote:
> [..]
> > I have about 100K DSL customers at this time and most all are households.
> > 65K wouldn't cover that.  At this point, I doubt that I'd require much
> > more than just asking and making sure the person is understanding what
> > they're asking for.  Mostly, that'd be the leased line customers.
> 
> Thus why didn't you request a larger prefix from ARIN then?
> Clearly you can justify it.
> 
> Then again, if you are going to provide /56's to home users, nobody will
> think you are a bad person and most people will be quite happy already.
> 
> In your case I would then reserve (probably topdown) /48's, for the
> larger sites/businesses and start allocating bottom-up for /56's to
> endusers.
> 

Another idea would be to give each non-/48 customer the
first /56 out of each /48. If you started out with a /30 or /31 RIR block , by
the time you run out of /48s, you can either start using up the
subsequent /56s out of the first /48, as it's likely that the first /56
customer out of the /48 would have needed the /48 by that time.
Alternatively you might have become more comfortable with giving each
customer a /48, and wouldn't require any of them to renumber - they'd
just have to shorten their prefix length.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Scott Weeks]

--- [EMAIL PROTECTED] wrote:
From: Jeroen Massar <[EMAIL PROTECTED]>

Scott Weeks wrote:
[..]
> I have about 100K DSL customers at this time and most all are households.
> 65K wouldn't cover that.  At this point, I doubt that I'd require much
> more than just asking and making sure the person is understanding what
> they're asking for.  Mostly, that'd be the leased line customers.

Thus why didn't you request a larger prefix from ARIN then?
Clearly you can justify it.

Then again, if you are going to provide /56's to home users, nobody will
think you are a bad person and most people will be quite happy already.

In your case I would then reserve (probably topdown) /48's, for the
larger sites/businesses and start allocating bottom-up for /56's to
endusers.
-

I haven't requested anything yet.  That's why I came to you folks.  To learn 
and then get busy on it.  Thanks for your top-down and bottom-up idea.  I will 
probably also intersperse /56s in between allocations as well; filling them in 
later if it ever gets to that.

scott

Re: v6 subnet size for DSL & leased line customers

[Jeroen Massar]

Scott Weeks wrote:
[..]
> I have about 100K DSL customers at this time and most all are households.
> 65K wouldn't cover that.  At this point, I doubt that I'd require much
> more than just asking and making sure the person is understanding what
> they're asking for.  Mostly, that'd be the leased line customers.

Thus why didn't you request a larger prefix from ARIN then?
Clearly you can justify it.

Then again, if you are going to provide /56's to home users, nobody will
think you are a bad person and most people will be quite happy already.

In your case I would then reserve (probably topdown) /48's, for the
larger sites/businesses and start allocating bottom-up for /56's to
endusers.

Greets,
 Jeroen




signature.asc
Description: OpenPGP digital signature

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sat, 29 Dec 2007 15:14:25 -0500
Marshall Eubanks <[EMAIL PROTECTED]> wrote:

> 
> On Dec 27, 2007, at 11:19 PM, Mark Smith wrote:
> 
> >
> > On Fri, 28 Dec 2007 12:57:45 +0900
> > Randy Bush <[EMAIL PROTECTED]> wrote:
> >
> >
> 
> Would it be possible to find the even part of this paper ? This  
> version only has the odd numbered pages.
> 

Here's where I got the version I first read. The full text/pdf is
available if you have or create yourself an ACM login :

http://portal.acm.org/citation.cfm?id=800081.802680



Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sat, 29 Dec 2007 15:14:25 -0500
Marshall Eubanks <[EMAIL PROTECTED]> wrote:

> 
> On Dec 27, 2007, at 11:19 PM, Mark Smith wrote:
> 
> >
> > On Fri, 28 Dec 2007 12:57:45 +0900
> > Randy Bush <[EMAIL PROTECTED]> wrote:
> >
> >>> Ever calculated how many Ethernet nodes you can attach to a  
> >>> single LAN
> >>> with 2^46 unicast addresses?
> >>
> >> you mean operationally successfully, or just for marketing glossies?
> >>
> >
> > Theoretically. What I find a bit hard to understand is peoples'
> > seemingly complete acceptance of the 'gross' amount of ethernet  
> > address
> > space there is available with 46 bits available for unicast addressing
> > on a single LAN segment, yet confusion and struggle over the  
> > allocation
> > of additional IPv6 bits addressing bits for the same purpose - the
> > operational convenience of having addressing "work out of the box" or
> > be simpler to understand and easier to work with.
> >
> > Once I realised that IPv6's fixed sized node addressing model was
> > similar to Ethernet's, I then started wondering why Ethernet was like
> > it was - and then found a paper that explains it :
> >
> > "48-bit Absolute Internet and Ethernet Host Numbers"
> > http://ethernethistory.typepad.com/papers/HostNumbers.pdf
> >
> 
> Would it be possible to find the even part of this paper ? This  
> version only has the odd numbered pages.
> 

Hmm, you're right. The version I originally read was from somewhere
else, and that was complete. I figured this one was more "original" as
it's on one of the papers author's websites, so I've remembered that
one, and even deleted my original electronic copy for this one. I'll try to find
the other copy.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Scott Weeks]

--- [EMAIL PROTECTED] wrote:
From: Mark Smith <[EMAIL PROTECTED]>

On Thu, 27 Dec 2007 18:08:10 -0800
"Scott Weeks" <[EMAIL PROTECTED]> wrote:

> I am thinking of a /56 for everyone and a /48 on request.
 

Out of curiosity, what in form would a request for a /48 need to be? A
checkbox on the application form, or some sort of written
justification? Remember that with an initial RIR allocation of a /32,
you've got 65K /48s ... so they're pretty cheap to give away.
---


I have about 100K DSL customers at this time and most all are households.  65K 
wouldn't cover that.  At this point, I doubt that I'd require much more than 
just asking and making sure the person is understanding what they're asking 
for.  Mostly, that'd be the leased line customers.

scott

Re: v6 subnet size for DSL & leased line customers

[Marshall Eubanks]

On Dec 27, 2007, at 11:19 PM, Mark Smith wrote:



On Fri, 28 Dec 2007 12:57:45 +0900
Randy Bush <[EMAIL PROTECTED]> wrote:

Ever calculated how many Ethernet nodes you can attach to a  
single LAN

with 2^46 unicast addresses?


you mean operationally successfully, or just for marketing glossies?



Theoretically. What I find a bit hard to understand is peoples'
seemingly complete acceptance of the 'gross' amount of ethernet  
address

space there is available with 46 bits available for unicast addressing
on a single LAN segment, yet confusion and struggle over the  
allocation

of additional IPv6 bits addressing bits for the same purpose - the
operational convenience of having addressing "work out of the box" or
be simpler to understand and easier to work with.

Once I realised that IPv6's fixed sized node addressing model was
similar to Ethernet's, I then started wondering why Ethernet was like
it was - and then found a paper that explains it :

"48-bit Absolute Internet and Ethernet Host Numbers"
http://ethernethistory.typepad.com/papers/HostNumbers.pdf



Would it be possible to find the even part of this paper ? This  
version only has the odd numbered pages.


Regards
Marshall



Regards,
Mark.

--

"Sheep are slow and tasty, and therefore must remain  
constantly

 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Robert E. Seastrom]

Mark Smith <[EMAIL PROTECTED]> writes:

> On Thu, 27 Dec 2007 21:50:01 -0500
> "Robert E. Seastrom" <[EMAIL PROTECTED]> wrote:
>
>> I'd really, really, really like to have DHCP6 on the Mac.  Autoconfig
>> is not sufficient for this task unless there is some kind of trick you
>> can do to make the eui-64 come out the same for both interfaces (don't
>> think so).
>
> Don't know if Mac's can do bridging, but under Linux, all you'd need to
> do would be create bridge instance, assign the two or more interfaces to the
> bridge, and have DHCPv6 use the bridge virtual interface.

The problem is that there is no DHCPv6 for the Mac (well, I suppose I
could try building it by hand and see how far I get).  I'm pretty sure
that Macs aren't set up to do a layer 2 bridge group between their
interfaces, and moreover I think this is risky behavior in terms of
creating a loop if something goes wrong on the laptop even if the host
OS supports it.

---rob

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Thu, 27 Dec 2007 21:50:01 -0500
"Robert E. Seastrom" <[EMAIL PROTECTED]> wrote:

> 
> 
> Leo Bicknell <[EMAIL PROTECTED]> writes:
> 

> 
> I'd really, really, really like to have DHCP6 on the Mac.  Autoconfig
> is not sufficient for this task unless there is some kind of trick you
> can do to make the eui-64 come out the same for both interfaces (don't
> think so).
> 

Don't know if Mac's can do bridging, but under Linux, all you'd need to
do would be create bridge instance, assign the two or more interfaces to the
bridge, and have DHCPv6 use the bridge virtual interface.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

> It plausible that if one were to assign a single /64 and reserve a 56 to
> delegate per customer

as a provider, where is the win in this for me?  the space is 'lost',
i.e. committed, and i increase provisioning hassles, though maybe mildly
if i am skillful.  if/when the rirs sober up about ipv6 justification, i
will have a hard time showing an hd ratio without a lot of zeros to the
immediate right of the decimal point.

or would you suggest that i recover the committed space if unused?
under what conditions?  after how long?  and, when i recover, do i
allocate the second (or 42nd) /64 to a new customer, leaving them a
smaller cushion than the first user of that /56 received?

no easy answers.  but yes, giving them a /56 off the bat feels a bit
reminiscent of giving them a /24 in ipv4.

randy

Re: v6 subnet size for DSL & leased line customers

[Joel Jaeggli]

Randy Bush wrote:
>>> vendors, like everyone else, will do what is in their best interests.
>>> as i am an operator, not a vendor, that is often not what is in my best
>>> interest, marketing literature aside.  i believe it benefits the ops
>>> community to be honest when the two do not seem to coincide.
>> If the ops community doesn't provide enough addresses and a way to use
>> them then the vendors will do the same thing they did in v4.
> 
> i presume you mean nat v6/v6.  this would be a real mess and i don't
> think anyone is contending it is desirable.  but this discussion is
> ostensibly operators trying to understand what is actually appropriate
> and useful for a class of customers, i believe those of the consumer,
> soho, and similar scale.
> 
> to summarize the positions i think i have heard
>   o one /64 subnet per device, but the proponent gave no estimate of the
> number of devices
>   o /48
>   o /56
>   o /64

It plausible that if one were to assign a single /64 and reserve a 56 to
delegate per customer that you could number about 16 million customers
per /32 with a few hundred thousand /64s remaining for infrastrucuture.
size of an agregate for a pop might be /48 (~250 customers) to /40 (65k
customers) to /36 (1 million customers)

A large retail isp might under those circumstances be able to get away
with order of /28 to /30 in total.

> the latter three all assuming that the allocation would be different if
> the site had actual need and justification.
> 
> personally, i do not see an end site needing more than 256 subnets *by
> default*, though i can certainly believe a small minority of them need
> more and would use the escape clause.  so, if we, for the moment, stick
> to the one /64 per subnet religion, than a /56 seems sufficient for the
> default allocation.
> 
> personally, i have a hard time thinking that any but a teensie minority,
> who can use the escape clause, need more than 256.  hence, i just don't
> buy the /48 position.

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Fri, 28 Dec 2007 13:36:56 +0900
Adrian Chadd <[EMAIL PROTECTED]> wrote:

> 
> On Fri, Dec 28, 2007, Mark Smith wrote:
> 
> > Once I realised that IPv6's fixed sized node addressing model was
> > similar to Ethernet's, I then started wondering why Ethernet was like
> > it was - and then found a paper that explains it :
> > 
> > "48-bit Absolute Internet and Ethernet Host Numbers"
> > http://ethernethistory.typepad.com/papers/HostNumbers.pdf
> > 
> 
> Question. Whats the ethernet 48-bit MAC space usage atm? Does anyone
> have a graph showing an E-Day? :)
> 
> 

Apparently there's a foreseeable one, hence EUI-64s. Novell'll have to
extend their IPX node addressing to 64 bits.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Adrian Chadd]

On Fri, Dec 28, 2007, Mark Smith wrote:

> Once I realised that IPv6's fixed sized node addressing model was
> similar to Ethernet's, I then started wondering why Ethernet was like
> it was - and then found a paper that explains it :
> 
> "48-bit Absolute Internet and Ethernet Host Numbers"
> http://ethernethistory.typepad.com/papers/HostNumbers.pdf
> 

Question. Whats the ethernet 48-bit MAC space usage atm? Does anyone
have a graph showing an E-Day? :)




Adrian

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Fri, 28 Dec 2007 12:57:45 +0900
Randy Bush <[EMAIL PROTECTED]> wrote:

> > Ever calculated how many Ethernet nodes you can attach to a single LAN
> > with 2^46 unicast addresses?
> 
> you mean operationally successfully, or just for marketing glossies?
> 

Theoretically. What I find a bit hard to understand is peoples'
seemingly complete acceptance of the 'gross' amount of ethernet address
space there is available with 46 bits available for unicast addressing
on a single LAN segment, yet confusion and struggle over the allocation
of additional IPv6 bits addressing bits for the same purpose - the
operational convenience of having addressing "work out of the box" or
be simpler to understand and easier to work with.

Once I realised that IPv6's fixed sized node addressing model was
similar to Ethernet's, I then started wondering why Ethernet was like
it was - and then found a paper that explains it :

"48-bit Absolute Internet and Ethernet Host Numbers"
http://ethernethistory.typepad.com/papers/HostNumbers.pdf

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

> Ever calculated how many Ethernet nodes you can attach to a single LAN
> with 2^46 unicast addresses?

you mean operationally successfully, or just for marketing glossies?

randy

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Thu, 27 Dec 2007 18:08:10 -0800
"Scott Weeks" <[EMAIL PROTECTED]> wrote:

> 
> 
> 
> 
> First, thanks everyone for the discussion.  I learned more from this than a 
> LOT of other discussions on IPv6.  I now have a plan and I didn't before...
> 
> It looks to me that one really has to know his customer's needs to plan out 
> the allocation of IPv6 space.  That leads me to believe that a /56 is going 
> to work for everyone on this network because, at this time, only very, very 
> few of our largest customers might possibly have a need for more than 256 /64 
> subnets.  In fact, almost all household DSL customers here only have one LAN 
> and I could get away with /64s for them because they wouldn't know the 
> difference.  But in an effort to simplify the lives of the network folks here 
> I am thinking of a /56 for everyone and a /48 on request.
> 

Out of curiosity, what in form would a request for a /48 need to be? A
checkbox on the application form, or some sort of written
justification? Remember that with an initial RIR allocation of a /32,
you've got 65K /48s ... so they're pretty cheap to give away.

> Now I just gotta wrap my brain around 4.7x10^21 addresses for each customer.  
> Absolutely staggering.
> 

Ever calculated how many Ethernet nodes you can attach to a single LAN
with 2^46 unicast addresses? That's a staggering number too.

Regards,
Mark.

> scott
> 
> 
> 
> --- [EMAIL PROTECTED] wrote:
> 
> From: Randy Bush <[EMAIL PROTECTED]>
> To: Joel Jaeggli <[EMAIL PROTECTED]>
> CC: nanog@merit.edu
> Subject: Re: v6 subnet size for DSL & leased line customers
> Date: Thu, 27 Dec 2007 13:19:27 +0900
> 
> 
> >> vendors, like everyone else, will do what is in their best interests.
> >> as i am an operator, not a vendor, that is often not what is in my best
> >> interest, marketing literature aside.  i believe it benefits the ops
> >> community to be honest when the two do not seem to coincide.
> > If the ops community doesn't provide enough addresses and a way to use
> > them then the vendors will do the same thing they did in v4.
> 
> i presume you mean nat v6/v6.  this would be a real mess and i don't
> think anyone is contending it is desirable.  but this discussion is
> ostensibly operators trying to understand what is actually appropriate
> and useful for a class of customers, i believe those of the consumer,
> soho, and similar scale.
> 
> to summarize the positions i think i have heard
>   o one /64 subnet per device, but the proponent gave no estimate of the
> number of devices
>   o /48
>   o /56
>   o /64
> the latter three all assuming that the allocation would be different if
> the site had actual need and justification.
> 
> personally, i do not see an end site needing more than 256 subnets *by
> default*, though i can certainly believe a small minority of them need
> more and would use the escape clause.  so, if we, for the moment, stick
> to the one /64 per subnet religion, than a /56 seems sufficient for the
> default allocation.
> 
> personally, i have a hard time thinking that any but a teensie minority,
> who can use the escape clause, need more than 256.  hence, i just don't
> buy the /48 position.
> 
> personally, i agree that one subnet is likely to be insufficient in a
> large proportion of cases.  so keeping to the /64 per subnet religion, a
> /64 per site is insufficient for the default.
> 
> still personally, i think the one /64 subnet per device is analogous to
> one receptacle per mains breaker, i.e. not sensible.
> 
> > there are three legs to the tripod
> > network operator
> > user
> > equipment manufacturer
> > They have (or should have) a mutual interest in:
> > Transparent and automatic configuration of devices.
> 
> as you have seen from chris's excellent post [0] on this one, one size
> does not fit all.  this is likely another worthwhile, but separate,
> discussion.
> 
> > The assignment of globally routable addresses to internet
> > connected devices
> 
> i suspect that there are folk out there who equate nat with security.  i
> suspect we both think them misguided.
> 
> > The user having some control over what crosses the boundry
> > between their network and the operators.
> 
> yup
> 
> randy
> 
> ---
> 
> [0] - <http://www.merit.edu/mail.archives/nanog/msg04887.html>
> 
> 


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: [DCHPv6] was Re: v6 subnet size for DSL & leased line customers

[David Barak]

I have a modest proposal for providing the functionality of DHCPv4 in IPv6 
autoconf:

How about using the mechanism in RFC 5075 to specify all of these variables as 
RA flags?

And as long as the variables also get defined as DHCPv6 fields, perhaps we 
could plan on having prefix delegation include these options, which the 
requesting router could then turn around and include in the RAs sent out on the 
link toward the customer.

Am I missing something?

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com


--- On Thu, 12/27/07, James R. Cutler <[EMAIL PROTECTED]> wrote:

> From: James R. Cutler <[EMAIL PROTECTED]>
> Subject: [DCHPv6] was Re: v6 subnet size for DSL & leased line customers
> To: "North American Network Operators Group" 
> Date: Thursday, December 27, 2007, 9:37 PM
> And, besides the list forwarded below,
> Designated printers,
> Preferred DNS Servers,
> and, maybe, more.
> 
> Even in a large enterprise, the ratio of
> "routers" to DHCP servers  
> makes control of many end system parameters via DHCP a
> management win  
> compared to configuration of "routers" with this
> "non-network core"  
> data.  (In case I was to abstruse, It is cheaper to
> maintain end  
> system parameters in a smaller number of DHCP servers than
> in a  
> larger number of "routers".)
> 
> This is completely separate from the fact that many
> experienced  
> router engineers are smart enough configure routers with
> NTP server  
> addresses in preference to DNS names, and likewise for many
> other  
> parameters.
> 
> The end system population has requirements which respond
> much more  
> dynamically to business requirements than do router
> configurations,  
> which respond mostly to wiring configurations which are, by
>  
> comparison, static.  The statement that DHCP is not needed
> for IPv6  
> packet routing may well be exactly accurate.  The absence
> of good  
> DHCP support in IPv6 has costly consequences for enterprise
>  
> management, of which IP routing is a small part.
> 
> You have seen this before from me:  Consider the
> Customer/Business  
> Management viewpoint, not just that of routing packets
> around between  
> boxes.  Pull your head out of your patch panel and look at
> all the  
> business requirements.  If you can show me a more cost
> effective way  
> to distribute all the parameters mentioned here to all end
> systems,  
> I'll support it.  In the meantime, don't use
> religious arguments to  
> prevent me from using whatever is appropriate to manage my
> business.   
> I'll even use NAT boxes, if there is no equivalently
> affordable  
> stateful firewall box!
> 
>   Cutler
> 
> Begin forwarded message:
> 
> > From: Leo Bicknell <[EMAIL PROTECTED]>
> > Date: December 27, 2007 7:33:08 PM EST
> > To: North American Network Operators Group
> 
> > Subject: Re: v6 subnet size for DSL & leased line
> customers
> >
> > In a message written on Thu, Dec 27, 2007 at
> 10:57:59PM +0100,  
> > Iljitsch van Beijnum wrote:
> >> It is wih IPv6: you just connect the ethernet
> cable and the RAs take
> >> care of the rest. _You_ _really_ _don't_
> _need_ _DHCP_ _for_ _IPv6_.
> >> If you need extreme control then manual
> configuration will give you
> >> that, which may be appropriate in some cases, such
> as servers.
> >
> > Really.  I didn't know RA's could:
> >
> > - Configure NTP servers for me.
> > - Tell me where to netboot from.
> > - Enter dynamic DNS entries in the DNS tree for me.
> > - Tell me my domain name.
> > - Tell me the VLAN to use for IP Telephony.
> >
> > Those are things I use on a regular basis I'd
> really rather not
> > manually configure.
> >
> > -- 
> >Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
> > PGP keys at http://www.ufp.org/~bicknell/
> > Read TMBG List - [EMAIL PROTECTED],
> www.tmbg.org
> 
> James R. Cutler
> [EMAIL PROTECTED]


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: v6 subnet size for DSL & leased line customers

[Marshall Eubanks]

On Dec 27, 2007, at 9:50 PM, Robert E. Seastrom wrote:




Leo Bicknell <[EMAIL PROTECTED]> writes:

In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100,  
Iljitsch van Beijnum wrote:

It is wih IPv6: you just connect the ethernet cable and the RAs take
care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.
If you need extreme control then manual configuration will give you
that, which may be appropriate in some cases, such as servers.


Really.  I didn't know RA's could:

- Configure NTP servers for me.
- Tell me where to netboot from.
- Enter dynamic DNS entries in the DNS tree for me.
- Tell me my domain name.
- Tell me the VLAN to use for IP Telephony.

Those are things I use on a regular basis I'd really rather not
manually configure.


I'm running (native) IPv6 at home, and in the colo too.  Most of my
ssh sessions to personally owned machines go over v6.

My laptops (with a single exception) are Macs.  You may not be aware
that the Mac is fairly smart about which interface it uses for
connections - it will prefer the gigabit ethernet to the wireless when
it sees link...  it prefers wireless to dialup too.  Basically,
whenever you establish a new outgoing session it will use the "lowest
cost" interface to do the deed.

For IPv4, I have the same address manually assigned on the DHCP server
to both the gigabit ethernet's MAC address and the wireless
interface's MAC address.  This means that when I plug into the gige,
as I do for filesharing or backing some files up, the Mac uses the
gigabit ethernet.  When I unplug and carry the Mac to the conference
room, *all existing upper layer sessions are preserved* - TCP and
friends are blissfully unaware that a change has taken place; one
gratuitous arp so the router knows where to send the packets and we're
on our way again with nary a hiccup.  I don't have an ssh session
croak just because I connected or disconnected a cable.

I'd really, really, really like to have DHCP6 on the Mac.  Autoconfig
is not sufficient for this task unless there is some kind of trick you
can do to make the eui-64 come out the same for both interfaces (don't
think so).

Anyone from Apple reading this list?  :-)



Don't know, but I bet they read  the MacnetworkProg list - they are  
present on all the Apple hosted lists

I am on. See

http://lists.apple.com/mailman/listinfo/macnetworkprog  from

http://lists.apple.com/mailman/listinfo

Regards
Marshall


---Rob

Re: v6 subnet size for DSL & leased line customers

[Robert E. Seastrom]

Leo Bicknell <[EMAIL PROTECTED]> writes:

> In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van 
> Beijnum wrote:
>> It is wih IPv6: you just connect the ethernet cable and the RAs take  
>> care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.  
>> If you need extreme control then manual configuration will give you  
>> that, which may be appropriate in some cases, such as servers.
>
> Really.  I didn't know RA's could:
>
> - Configure NTP servers for me.
> - Tell me where to netboot from.
> - Enter dynamic DNS entries in the DNS tree for me.
> - Tell me my domain name.
> - Tell me the VLAN to use for IP Telephony.
>
> Those are things I use on a regular basis I'd really rather not
> manually configure.

I'm running (native) IPv6 at home, and in the colo too.  Most of my
ssh sessions to personally owned machines go over v6.

My laptops (with a single exception) are Macs.  You may not be aware
that the Mac is fairly smart about which interface it uses for
connections - it will prefer the gigabit ethernet to the wireless when
it sees link...  it prefers wireless to dialup too.  Basically,
whenever you establish a new outgoing session it will use the "lowest
cost" interface to do the deed.

For IPv4, I have the same address manually assigned on the DHCP server
to both the gigabit ethernet's MAC address and the wireless
interface's MAC address.  This means that when I plug into the gige,
as I do for filesharing or backing some files up, the Mac uses the
gigabit ethernet.  When I unplug and carry the Mac to the conference
room, *all existing upper layer sessions are preserved* - TCP and
friends are blissfully unaware that a change has taken place; one
gratuitous arp so the router knows where to send the packets and we're
on our way again with nary a hiccup.  I don't have an ssh session
croak just because I connected or disconnected a cable.

I'd really, really, really like to have DHCP6 on the Mac.  Autoconfig
is not sufficient for this task unless there is some kind of trick you
can do to make the eui-64 come out the same for both interfaces (don't
think so).

Anyone from Apple reading this list?  :-)

---Rob

[DCHPv6] was Re: v6 subnet size for DSL & leased line customers

[James R. Cutler]

And, besides the list forwarded below,
Designated printers,
Preferred DNS Servers,
and, maybe, more.

Even in a large enterprise, the ratio of "routers" to DHCP servers  
makes control of many end system parameters via DHCP a management win  
compared to configuration of "routers" with this "non-network core"  
data.  (In case I was to abstruse, It is cheaper to maintain end  
system parameters in a smaller number of DHCP servers than in a  
larger number of "routers".)


This is completely separate from the fact that many experienced  
router engineers are smart enough configure routers with NTP server  
addresses in preference to DNS names, and likewise for many other  
parameters.


The end system population has requirements which respond much more  
dynamically to business requirements than do router configurations,  
which respond mostly to wiring configurations which are, by  
comparison, static.  The statement that DHCP is not needed for IPv6  
packet routing may well be exactly accurate.  The absence of good  
DHCP support in IPv6 has costly consequences for enterprise  
management, of which IP routing is a small part.


You have seen this before from me:  Consider the Customer/Business  
Management viewpoint, not just that of routing packets around between  
boxes.  Pull your head out of your patch panel and look at all the  
business requirements.  If you can show me a more cost effective way  
to distribute all the parameters mentioned here to all end systems,  
I'll support it.  In the meantime, don't use religious arguments to  
prevent me from using whatever is appropriate to manage my business.   
I'll even use NAT boxes, if there is no equivalently affordable  
stateful firewall box!


Cutler

Begin forwarded message:


From: Leo Bicknell <[EMAIL PROTECTED]>
Date: December 27, 2007 7:33:08 PM EST
To: North American Network Operators Group 
Subject: Re: v6 subnet size for DSL & leased line customers

In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100,  
Iljitsch van Beijnum wrote:

It is wih IPv6: you just connect the ethernet cable and the RAs take
care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.
If you need extreme control then manual configuration will give you
that, which may be appropriate in some cases, such as servers.


Really.  I didn't know RA's could:

- Configure NTP servers for me.
- Tell me where to netboot from.
- Enter dynamic DNS entries in the DNS tree for me.
- Tell me my domain name.
- Tell me the VLAN to use for IP Telephony.

Those are things I use on a regular basis I'd really rather not
manually configure.

--
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


James R. Cutler
[EMAIL PROTECTED]

Re: v6 subnet size for DSL & leased line customers

[Scott Weeks]

First, thanks everyone for the discussion.  I learned more from this than a LOT 
of other discussions on IPv6.  I now have a plan and I didn't before...

It looks to me that one really has to know his customer's needs to plan out the 
allocation of IPv6 space.  That leads me to believe that a /56 is going to work 
for everyone on this network because, at this time, only very, very few of our 
largest customers might possibly have a need for more than 256 /64 subnets.  In 
fact, almost all household DSL customers here only have one LAN and I could get 
away with /64s for them because they wouldn't know the difference.  But in an 
effort to simplify the lives of the network folks here I am thinking of a /56 
for everyone and a /48 on request.

Now I just gotta wrap my brain around 4.7x10^21 addresses for each customer.  
Absolutely staggering.

scott



--- [EMAIL PROTECTED] wrote:

From: Randy Bush <[EMAIL PROTECTED]>
To: Joel Jaeggli <[EMAIL PROTECTED]>
CC: nanog@merit.edu
Subject: Re: v6 subnet size for DSL & leased line customers
Date: Thu, 27 Dec 2007 13:19:27 +0900


>> vendors, like everyone else, will do what is in their best interests.
>> as i am an operator, not a vendor, that is often not what is in my best
>> interest, marketing literature aside.  i believe it benefits the ops
>> community to be honest when the two do not seem to coincide.
> If the ops community doesn't provide enough addresses and a way to use
> them then the vendors will do the same thing they did in v4.

i presume you mean nat v6/v6.  this would be a real mess and i don't
think anyone is contending it is desirable.  but this discussion is
ostensibly operators trying to understand what is actually appropriate
and useful for a class of customers, i believe those of the consumer,
soho, and similar scale.

to summarize the positions i think i have heard
  o one /64 subnet per device, but the proponent gave no estimate of the
number of devices
  o /48
  o /56
  o /64
the latter three all assuming that the allocation would be different if
the site had actual need and justification.

personally, i do not see an end site needing more than 256 subnets *by
default*, though i can certainly believe a small minority of them need
more and would use the escape clause.  so, if we, for the moment, stick
to the one /64 per subnet religion, than a /56 seems sufficient for the
default allocation.

personally, i have a hard time thinking that any but a teensie minority,
who can use the escape clause, need more than 256.  hence, i just don't
buy the /48 position.

personally, i agree that one subnet is likely to be insufficient in a
large proportion of cases.  so keeping to the /64 per subnet religion, a
/64 per site is insufficient for the default.

still personally, i think the one /64 subnet per device is analogous to
one receptacle per mains breaker, i.e. not sensible.

> there are three legs to the tripod
>   network operator
>   user
>   equipment manufacturer
> They have (or should have) a mutual interest in:
>   Transparent and automatic configuration of devices.

as you have seen from chris's excellent post [0] on this one, one size
does not fit all.  this is likely another worthwhile, but separate,
discussion.

> The assignment of globally routable addresses to internet
> connected devices

i suspect that there are folk out there who equate nat with security.  i
suspect we both think them misguided.

> The user having some control over what crosses the boundry
> between their network and the operators.

yup

randy

---

[0] - <http://www.merit.edu/mail.archives/nanog/msg04887.html>

Re: v6 subnet size for DSL & leased line customers

[Leo Bicknell]

In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van 
Beijnum wrote:
> It is wih IPv6: you just connect the ethernet cable and the RAs take  
> care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.  
> If you need extreme control then manual configuration will give you  
> that, which may be appropriate in some cases, such as servers.

Really.  I didn't know RA's could:

- Configure NTP servers for me.
- Tell me where to netboot from.
- Enter dynamic DNS entries in the DNS tree for me.
- Tell me my domain name.
- Tell me the VLAN to use for IP Telephony.

Those are things I use on a regular basis I'd really rather not
manually configure.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


pgpy9pOPQJ1De.pgp
Description: PGP signature

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Thu, 27 Dec 2007 22:57:59 +0100
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> 
> On 27 dec 2007, at 20:26, Christopher Morrow wrote:
> 



> 
> Taken to its extreme "feature parity" means a search and replace of  
> all IPv4 specs to make every instance of "32 bits" "128 bits" but not  
> changing anything else. That's not what IPv6 is.

Exactly.

IPv6 is similar enough to IPv4 that it makes it easier to learn than if
it were a completely new and unrelated protocol.

It's different enough that you need to take each of the concepts and
practices that you know and have used for IPv4 for many years and try
to objectively evaluate whether they're still valid for IPv6. IPv6 has
features that IPv4 has never had, but have existed in IPX and Appletalk
since they were designed many years ago. If people have the time,
learning about those protocols might help with more easily learning
about IPv6.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 27 dec 2007, at 20:26, Christopher Morrow wrote:


With IPv4, a lot of these features are developed by vendors and
(sometimes) later standardized in the IETF or elsewhere. With IPv6,
the vendors haven't quite caught up with the IETF standardization
efforts yet, so the situation is samewhat different. For instance,
SEND/CGA is excellent work, but we've only recently seen the first
implementations.



first implementations, in a protocol that's 'fully baked' (according
to ietf closing down the v6 WG) and been in 'production' for 15 years?


You suggest that I said that IPv6 has only recently seen the first  
implementations. I was talking about CGA/SEND, not IPv6 proper, which  
was standardized some 12 years ago.



for features that have existed in the v4 network for 5+ years? ouch...
This gets back to my point about having feature parity


Some of the "features" of IPv4 are actually glaring holes that some  
people have found a use for. Also, SEND is something that doesn't  
exist in IPv4 so your complaint doesn't apply here.



and the fact
that that is important. People have deployed rather large environments
that require these features, not having them is a step backwards and
painful for the operators in question.


Please direct your feature request to your favorite vendors...


What this all boils down to is that if you want to deploy DHCPv6 you
need to install software on a lot of systems and modify a lot of


'the largest deployed platform' already has this built-in, yes?  
(vista/xp)


Vista: yes, it seems. XP, no so much. Windows XP can't even do DNS  
lookups over IPv6, which basically means that you can't use an XP  
machine on an IPv6-only network.



If you're going to do all that, it's easier to simply
configure this stuff manually. The only downside to that is that it's



you are crazy... seriously, have you walked around to 10k or 50k
machines or attempted to get helpdesky people to do the same? have you
considered that this all works fine in v4, is tied into my OSS
backends and is a part of my business process? Getting some new
software (firefox is a fine example) deployed to 50k workstations is
an overnight event... SMS (or whatever the new MS equivalent is) rolls
out the software update, there are many other options (tivoli,
ca-unicenter, custom-foo) which will also do this work for you,
getting proper and dynamic setup of IP info (my earlier example of
resolvers) isn't quite as simple unless you use dhcp.


It is wih IPv6: you just connect the ethernet cable and the RAs take  
care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.  
If you need extreme control then manual configuration will give you  
that, which may be appropriate in some cases, such as servers.



just saying 'dhcpv6 isnt possible use autoconf' is never going to be
acceptable.


Never said it isn't possible. But unlike with IPv4, where DHCP is the  
default answer unless you're really sure you need manual  
configuration, DHCPv6 isn't the default answer for IPv6.



That being said, please go to your vendors and tell them what you
need. Preferably at a high level, so they can provide the
functionality in the optimal way, rather than just revert back to the
IPv4 way of doing things.



also be sure to let your standards body(s) know that some form of
feature parity is relevant. I think often there is a missing message
between operators and the other folks :( this clearly (to me atleast)
seems like one of those areas.


Taken to its extreme "feature parity" means a search and replace of  
all IPv4 specs to make every instance of "32 bits" "128 bits" but not  
changing anything else. That's not what IPv6 is.

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 27 dec 2007, at 12:44, [EMAIL PROTECTED] wrote:


I agree that DHCPv6 prefix delegation (for instance a /56) to a CPE
which provides configuration to hosts on its LAN side sounds like a
reasonable model. It requires the customer to have a CPE with actual
*router* functionality, as opposed to just a bridge. This is different
from today's requirements, but may not be unreasonable.


Ok, that would be CPE == modem. Another line of thought would be a  
bridging modem + a routing CPE that the customer provides. This would  
be similar to the home "routers" that you can buy today. (A lot of  
ISPs, especially in the are I just moved to, insist on providing you  
with a "free" "router" rather than just a modem, yuck!)


Ideally, a bridging modem would be able to talk to both individual  
hosts, just like it can on IPv4, or to a router provided by the  
customer. But unlike with IPv4, these modes of operation would have to  
be different in the absense of NAT. Providing a prefix to a user is  
actually the simple part, because there is really only one way to do  
it (short of manual configuration): DHCPv6 prefix delegation. The  
trouble is how ISP equipment talks to the first IPv6 device on the  
customer side. The easy way would be to have a separate VLAN and IPv6  
subnet for that for each customer but I gather that means more  
expensive equipment. Using the IPv4 model with DHCPv6 wouldn't work  
well because of the low DHCPv6 adoption. (This problem may or may not  
go away in time; I gather that Vista has it but that Apple isn't  
interested in adopting DHCPv6.)


However, rather than snooping DHCP messages and inserting DHCP  
options, with IPv6 DSL/cable equipment on the ISP side (or even the  
modem) could intercept and modify router advertisements so each  
customer gets their own prefix advertised. If we then do some ingress  
filtering based on that prefix and force all traffic through the first  
IPv6 router on the ISP side this could work very well. Interestingly,  
in IPv6 there is no need for a default gateway to have an address in  
the subnet prefix that hosts use. So the problem that you'd have with  
this in IPv4, that two neighbors can't communicate because the hosts  
think they're on the same IP subnet but direct traffic between them is  
blocked, doesn't occur. (Unless the router sends redirects.)


On 27 dec 2007, at 13:11, Mark Smith wrote:


I think it's interesting CGAs are being discussed in the same email as
the one where you say you want to be able to express prefix length  
in DHCPv6 -

because I'm guessing you want that feature to be able to shorten node
addresses.


Actually I spoke up against that in the last IETF meeting. Maybe in 20  
years when we made such a mess of the other bits that we need to  
recover some of those interface identifier bits.


The issue with lacking a prefix length in DHCPv6 doesn't really lead  
to any trouble in normal operation, but it does make DHCPv6 mostly  
useless in one of the cases that it's advertised for: the situation  
where there is no router on the subnet. In that case, if host A gets  
2001::a and host B gets 2001::b but they don't know the subnet size,  
the conservative assumption is /128 which means that they can't  
communicate. Hardcoding /64 would be bad, even in router  
advertisements the prefix length is carried explicitly even though  
stateless autoconfig won't work if it's not 64.


On 27 dec 2007, at 13:19, Mark Smith wrote:


there are currently no ISPs and no CPEs that do
that, as far as I know.



I haven't had a chance to test it, but according to "Deploying IPv6
Networks", IOS can support DHCPv6 based prefix delegation. It even
supports multiple downstream interfaces on the CPE - you configure the
subnet number you want on each of the interfaces, and the CPE will
configure the DHCP-PD learned /48 on the front of them automatically
and then start announcing those prefixes in RAs out those interfaces.


You're absolutely right. For some reason it never connected in my  
brain that my Cisco 826/827 (I always forget which) ADSL router  
supports this, even with a 3 year old IOS. I think when I tested this  
I did so on a bunch of 2500s. But if you look at Apple's Airport  
Extreme base station, for instance, that box will only terminate a  
tunnel and not handle any kind of native IPv6 routing.


See http://www1.ietf.org/mail-archive/web/ipv6/current/msg08798.html  
for a small config example.


(I think someone said the Airport Extreme bridges IPv6 and routes IPv4  
(or maybe the other way around), which isn't true. You can configure  
it to bridge or do IPv4 NAT and separately from that to route between  
an IPv6 manual or 6to4 tunnel and the LAN ports (+ WAN port when  
bridging).)

Re: v6 subnet size for DSL & leased line customers

[Christopher Morrow]

On Dec 27, 2007 5:27 AM, Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
>

> With IPv4, a lot of these features are developed by vendors and
> (sometimes) later standardized in the IETF or elsewhere. With IPv6,
> the vendors haven't quite caught up with the IETF standardization
> efforts yet, so the situation is samewhat different. For instance,
> SEND/CGA is excellent work, but we've only recently seen the first
> implementations.

first implementations, in a protocol that's 'fully baked' (according
to ietf closing down the v6 WG) and been in 'production' for 15 years?
for features that have existed in the v4 network for 5+ years? ouch...
 This gets back to my point about having feature parity and the fact
that that is important. People have deployed rather large environments
that require these features, not having them is a step backwards and
painful for the operators in question.

>
> What this all boils down to is that if you want to deploy DHCPv6 you
> need to install software on a lot of systems and modify a lot of

'the largest deployed platform' already has this built-in, yes? (vista/xp)

> configurations. If you're going to do all that, it's easier to simply
> configure this stuff manually. The only downside to that is that it's
>

you are crazy... seriously, have you walked around to 10k or 50k
machines or attempted to get helpdesky people to do the same? have you
considered that this all works fine in v4, is tied into my OSS
backends and is a part of my business process? Getting some new
software (firefox is a fine example) deployed to 50k workstations is
an overnight event... SMS (or whatever the new MS equivalent is) rolls
out the software update, there are many other options (tivoli,
ca-unicenter, custom-foo) which will also do this work for you,
getting proper and dynamic setup of IP info (my earlier example of
resolvers) isn't quite as simple unless you use dhcp.

> not compatible with easy renumbering, but then, you need to do more
> than just automate address assignment to support easy renumbering.
>

sure, like deploy v6... wait, that doesn't do it either :( It's not
just renumbering, it's migration of services which the network
elements are reliant on (dns, wins, tftp-root/nfs-root...) tieing my
laptop to the same addr each time for some process including logs and
HR details and SoX compliance perhaps. This is a bighairy beast, just
saying 'dhcpv6 isnt possible use autoconf' is never going to be
acceptable.

> That being said, please go to your vendors and tell them what you
> need. Preferably at a high level, so they can provide the
> functionality in the optimal way, rather than just revert back to the
> IPv4 way of doing things.

also be sure to let your standards body(s) know that some form of
feature parity is relevant. I think often there is a missing message
between operators and the other folks :( this clearly (to me atleast)
seems like one of those areas.

-Chris

Re: v6 subnet size for DSL & leased line customers

[Leo Bicknell]

In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch van 
Beijnum wrote:
> 100% of the DHCP functionality). But apart from that, some of the  
> choices made along the way make DHCPv6 a lot harder to use than DHCP  
> for IPv4. Not only do you lack a default gateway (which is actually a  
> good thing for fate sharing reasons) but also a subnet prefix length  
> and any extra on-link prefixes. So even if you do address  
> configuration with DHCPv6 you need RAs for that other information.  

I would note, it's not too late to fix these problems.  We don't
have wide spread IPv6 deployment yet, and I can't imagine it's all
that hard to send a default gateway in DHCPv6, for example.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


pgpgZ7FayQI7H.pgp
Description: PGP signature

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Thu, 27 Dec 2007 12:11:54 +0100
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> 
> On 27 dec 2007, at 11:57, [EMAIL PROTECTED] wrote:
> 
> > "Configure this stuff manually" may work for a small number of
> > customers. It is highly undesirable (and probably won't be considered
> > at all) in an environment with, say, 1 million customers.
> 
> Of course not. But RAs on a subnet with a million customers doesn't  
> work either, nor does DHCP on a subnet with a million customers.
> 
> If we're talking about provisioning cable/DSL/FTTH users, that's a  
> completely different thing. Here, DHCPv6 prefix delegation to a CPE  
> which then provides configuration to hosts on its LAN side would be  
> the most appropriate option. However, the specifics of that model need  
> to be worked out as there are currently no ISPs and no CPEs that do  
> that, as far as I know.

I haven't had a chance to test it, but according to "Deploying IPv6
Networks", IOS can support DHCPv6 based prefix delegation. It even
supports multiple downstream interfaces on the CPE - you configure the
subnet number you want on each of the interfaces, and the CPE will
configure the DHCP-PD learned /48 on the front of them automatically
and then start announcing those prefixes in RAs out those interfaces.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Thu, 27 Dec 2007 11:27:13 +0100
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> 
> On 26 dec 2007, at 22:40, Leo Bicknell wrote:
> 



> 
> > It would be very interesting to me if the answer was "it's moot
> > because we're going to move to CGA's as a step forward"; it would
> > be equally interesting if the answer is "CGA isn't ready for prime
> > time / we can't deploy it for xyz reason, so IPv6 is less secure
> > than IPv4 today and that's a problem."
> 
> With IPv4, a lot of these features are developed by vendors and  
> (sometimes) later standardized in the IETF or elsewhere. With IPv6,  
> the vendors haven't quite caught up with the IETF standardization  
> efforts yet, so the situation is samewhat different. For instance,  
> SEND/CGA is excellent work, but we've only recently seen the first  
> implementations.
> 
> Personally, I'm not a big fan of DHCPv6. First of all, from a  
> philosophical standpoint: I believe that stateless autoconfiguration  
> is a better model in most cases (although it obviously doesn't support  
> 100% of the DHCP functionality). But apart from that, some of the  
> choices made along the way make DHCPv6 a lot harder to use than DHCP  
> for IPv4. Not only do you lack a default gateway (which is actually a  
> good thing for fate sharing reasons) but also a subnet prefix length  
> and any extra on-link prefixes.

I think it's interesting CGAs are being discussed in the same email as
the one where you say you want to be able to express prefix length in DHCPv6 -
because I'm guessing you want that feature to be able to shorten node
addresses.

One of the benefits of fixed length node addresses, at the 64 bit
boundary, is that it has made CGA much simpler - the CGA designers knew
from the outset that they were dealing with a single, fixed length 64
bit field to store the results of their crypto functions. If people had
different length autoconfigured or DHCPv6 learned addresses, not only
would CGA have to had be designed to support those varying field
lengths, increasing it's complexity (and therefore increasing
opportunities for implementation related security failure aka bugs with
security consequences), it's also likely that CGA would have had to
incorporate parameter checks to prevent people enabling it, when the
node address length they've chosen is too short for the security
strength CGA is designed to provide. If you don't perform these sorts
of checks, then too weak CGA, because of too short node addresses,
might give people a false sense of security - and I think that's far
worse than no security at all.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[sthaug]

> > "Configure this stuff manually" may work for a small number of
> > customers. It is highly undesirable (and probably won't be considered
> > at all) in an environment with, say, 1 million customers.
> 
> Of course not. But RAs on a subnet with a million customers doesn't  
> work either, nor does DHCP on a subnet with a million customers.

It wouldn't be a subnet with a million customers, of course. We would
typically have aggregation routers handling 5000 to 3 customers,
each connected via (in our case) point to point DSL links. Important
point here is that we *don't* want per-customer IPv4 (or IPv6) config
on the aggregation routers - this is what we have DHCP servers for.

> If we're talking about provisioning cable/DSL/FTTH users, that's a  
> completely different thing. Here, DHCPv6 prefix delegation to a CPE  
> which then provides configuration to hosts on its LAN side would be  
> the most appropriate option. However, the specifics of that model need  
> to be worked out as there are currently no ISPs and no CPEs that do  
> that, as far as I know.

I agree that DHCPv6 prefix delegation (for instance a /56) to a CPE
which provides configuration to hosts on its LAN side sounds like a
reasonable model. It requires the customer to have a CPE with actual
*router* functionality, as opposed to just a bridge. This is different
from today's requirements, but may not be unreasonable.

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 27 dec 2007, at 11:57, [EMAIL PROTECTED] wrote:


"Configure this stuff manually" may work for a small number of
customers. It is highly undesirable (and probably won't be considered
at all) in an environment with, say, 1 million customers.


Of course not. But RAs on a subnet with a million customers doesn't  
work either, nor does DHCP on a subnet with a million customers.


If we're talking about provisioning cable/DSL/FTTH users, that's a  
completely different thing. Here, DHCPv6 prefix delegation to a CPE  
which then provides configuration to hosts on its LAN side would be  
the most appropriate option. However, the specifics of that model need  
to be worked out as there are currently no ISPs and no CPEs that do  
that, as far as I know.

Re: v6 subnet size for DSL & leased line customers

[sthaug]

> Personally, I'm not a big fan of DHCPv6. First of all, from a  
> philosophical standpoint: I believe that stateless autoconfiguration  
> is a better model in most cases (although it obviously doesn't support  
> 100% of the DHCP functionality). But apart from that, some of the  
> choices made along the way make DHCPv6 a lot harder to use than DHCP  
> for IPv4. Not only do you lack a default gateway (which is actually a  
> good thing for fate sharing reasons) but also a subnet prefix length  
> and any extra on-link prefixes. So even if you do address  
> configuration with DHCPv6 you need RAs for that other information.  

Which is probably going to make IPv6 deployment slower in service
provider environments.

> There's also tons of ways to complicate your life by mixing stateless  
> autoconf and DHCPv6, especially since most systems don't support  
> DHCPv6 unless you install additional software. Last but not least,  
> DHCPv6 has a stateful mode that's appropriate for address assignment  
> or prefix delegation, and a stateless mode that's more efficient for  
> the configuration of information that's not client-specific.  
> Unfortunately, it's up to the client to initiate the desired mode.  
> Then there are the M and O bits in RAs that tell you whether to do  
> DHCPv6 but a number of DHCPv6 aficionados look like they want to  
> ignore those bits.

Again, this is something that's going to slow down deployment in
service provider environments. Providers are comfortable with the IPv4
DHCP model (which is definitely not stateless) and many of us would
like to keep this.

> What this all boils down to is that if you want to deploy DHCPv6 you  
> need to install software on a lot of systems and modify a lot of  
> configurations. If you're going to do all that, it's easier to simply  
> configure this stuff manually. The only downside to that is that it's  
> not compatible with easy renumbering, but then, you need to do more  
> than just automate address assignment to support easy renumbering.

"Configure this stuff manually" may work for a small number of
customers. It is highly undesirable (and probably won't be considered
at all) in an environment with, say, 1 million customers.

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 26 dec 2007, at 22:40, Leo Bicknell wrote:


If you're a shop that uses such features today (MAC/Port tracking,
DHCP snooping, etc) to "secure" your IPv4 infrastructure does IPv6
RA's represent a step backwards from a security perspective?  Would
IPv6 deployment be hindered until there is DHCPv6 snooping and
DHCPv6 is able to provide a default gateway, a-la how it is done
today in IPv4?



It would be very interesting to me if the answer was "it's moot
because we're going to move to CGA's as a step forward"; it would
be equally interesting if the answer is "CGA isn't ready for prime
time / we can't deploy it for xyz reason, so IPv6 is less secure
than IPv4 today and that's a problem."


With IPv4, a lot of these features are developed by vendors and  
(sometimes) later standardized in the IETF or elsewhere. With IPv6,  
the vendors haven't quite caught up with the IETF standardization  
efforts yet, so the situation is samewhat different. For instance,  
SEND/CGA is excellent work, but we've only recently seen the first  
implementations.


Personally, I'm not a big fan of DHCPv6. First of all, from a  
philosophical standpoint: I believe that stateless autoconfiguration  
is a better model in most cases (although it obviously doesn't support  
100% of the DHCP functionality). But apart from that, some of the  
choices made along the way make DHCPv6 a lot harder to use than DHCP  
for IPv4. Not only do you lack a default gateway (which is actually a  
good thing for fate sharing reasons) but also a subnet prefix length  
and any extra on-link prefixes. So even if you do address  
configuration with DHCPv6 you need RAs for that other information.  
There's also tons of ways to complicate your life by mixing stateless  
autoconf and DHCPv6, especially since most systems don't support  
DHCPv6 unless you install additional software. Last but not least,  
DHCPv6 has a stateful mode that's appropriate for address assignment  
or prefix delegation, and a stateless mode that's more efficient for  
the configuration of information that's not client-specific.  
Unfortunately, it's up to the client to initiate the desired mode.  
Then there are the M and O bits in RAs that tell you whether to do  
DHCPv6 but a number of DHCPv6 aficionados look like they want to  
ignore those bits.


What this all boils down to is that if you want to deploy DHCPv6 you  
need to install software on a lot of systems and modify a lot of  
configurations. If you're going to do all that, it's easier to simply  
configure this stuff manually. The only downside to that is that it's  
not compatible with easy renumbering, but then, you need to do more  
than just automate address assignment to support easy renumbering.


I don't think IPv6 address configuration in general and DHCPv6 in  
particular will ever be fully equivalent to how things work with IPv4.  
This is really the place where the differences between the two  
protocols are the biggest. For those of us who are familiar with IPX,  
AppleTalk, CLNP and IPv4: IPv6 basically uses the address  
configuration methods from all of those, no wonder it can get a bit  
complex.


That being said, please go to your vendors and tell them what you  
need. Preferably at a high level, so they can provide the  
functionality in the optimal way, rather than just revert back to the  
IPv4 way of doing things.

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

>> vendors, like everyone else, will do what is in their best interests.
>> as i am an operator, not a vendor, that is often not what is in my best
>> interest, marketing literature aside.  i believe it benefits the ops
>> community to be honest when the two do not seem to coincide.
> If the ops community doesn't provide enough addresses and a way to use
> them then the vendors will do the same thing they did in v4.

i presume you mean nat v6/v6.  this would be a real mess and i don't
think anyone is contending it is desirable.  but this discussion is
ostensibly operators trying to understand what is actually appropriate
and useful for a class of customers, i believe those of the consumer,
soho, and similar scale.

to summarize the positions i think i have heard
  o one /64 subnet per device, but the proponent gave no estimate of the
number of devices
  o /48
  o /56
  o /64
the latter three all assuming that the allocation would be different if
the site had actual need and justification.

personally, i do not see an end site needing more than 256 subnets *by
default*, though i can certainly believe a small minority of them need
more and would use the escape clause.  so, if we, for the moment, stick
to the one /64 per subnet religion, than a /56 seems sufficient for the
default allocation.

personally, i have a hard time thinking that any but a teensie minority,
who can use the escape clause, need more than 256.  hence, i just don't
buy the /48 position.

personally, i agree that one subnet is likely to be insufficient in a
large proportion of cases.  so keeping to the /64 per subnet religion, a
/64 per site is insufficient for the default.

still personally, i think the one /64 subnet per device is analogous to
one receptacle per mains breaker, i.e. not sensible.

> there are three legs to the tripod
>   network operator
>   user
>   equipment manufacturer
> They have (or should have) a mutual interest in:
>   Transparent and automatic configuration of devices.

as you have seen from chris's excellent post [0] on this one, one size
does not fit all.  this is likely another worthwhile, but separate,
discussion.

> The assignment of globally routable addresses to internet
> connected devices

i suspect that there are folk out there who equate nat with security.  i
suspect we both think them misguided.

> The user having some control over what crosses the boundry
> between their network and the operators.

yup

randy

---

[0] - 

Re: v6 subnet size for DSL & leased line customers

[Leo Bicknell]

In a message written on Wed, Dec 26, 2007 at 09:19:54PM +0100, Iljitsch van 
Beijnum wrote:
> Many switches can enforce a MAC/port relationship, so that MAC  
> addresses can't be spoofed.

Which gets to the crux of my question.

If you're a shop that uses such features today (MAC/Port tracking,
DHCP snooping, etc) to "secure" your IPv4 infrastructure does IPv6
RA's represent a step backwards from a security perspective?  Would
IPv6 deployment be hindered until there is DHCPv6 snooping and
DHCPv6 is able to provide a default gateway, a-la how it is done
today in IPv4?

It would be very interesting to me if the answer was "it's moot
because we're going to move to CGA's as a step forward"; it would
be equally interesting if the answer is "CGA isn't ready for prime
time / we can't deploy it for xyz reason, so IPv6 is less secure
than IPv4 today and that's a problem."

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


pgpFRvP23uRdF.pgp
Description: PGP signature

Re: v6 subnet size for DSL & leased line customers

[Joe Maimon]

Tony Li wrote:




On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote:



It's unlikely that it will matter.  In practice, ICMP router  discovery 
died a long time ago, thanks to neglect.  Host vendors  didn't adopt it, 
and it languished.  The problem eventually got  solved with HSRP and its 
clone, VRRP.


Its been available from microsoft since windows2000, and according to 
documentation, on by default. I am not quite sure this can be blamed on 
vendors as opposed to users.


http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/33574.mspx?mfr=true

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 26 dec 2007, at 19:22, Tony Li wrote:

This doesn't resolve the real underlying problem: Ethernet is  
inherently insecure.  MAC addresses can be forged, protocols (ARP,  
ND) can be forged and at this point, there's not much that we can do  
about it.  Architecturally, we need authentication over each and  
every control plane packet sent.  Getting there without invoking the  
full complexity of a public key infrastructure is still an unsolved  
problem, AFAIK.


Actually, for this particular purpose, this is mostly a solved  
problem, although there is of course no free lunch.


Many switches can enforce a MAC/port relationship, so that MAC  
addresses can't be spoofed.


Neighbor discovery and router advertisements can be secured with SEND  
(SEcure Neighbor Discovery). This happens through CGAs,  
cryptograpically generated addresses. Basically, the lower 64 bits of  
the IPv6 address contains a hash over a public key. This makes it  
possible to prove ownership over an address.


The not free part is that you need to configure certificates for trust  
relationships = the routers that may be default gateways.

Re: v6 subnet size for DSL & leased line customers

[Tony Li]

On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote:

In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500,  
Kevin Loch wrote:
RA is a shotgun.  All hosts on a segment get the same gateway.  I  
have
no idea what a host on multiple segments with different gateways  
would

do.  Hosting environments can get complex thanks to customer


I would like to point out that in IPv4 we have ICMP Router
Advertisement messages.  I have never seen them used on a production
network.  I know one of the worries is security, that a compromised  
host

could send out advertisements, drawing traffic to it that it can then
snoop and pass on to the real gateway.

Having not looked in great detail, I am unclear if IPv6 has done
something to fix this concern or not.

Is this feature going to get turned off when the first worm comes  
along

that spoofs RA's




It's unlikely that it will matter.  In practice, ICMP router  
discovery died a long time ago, thanks to neglect.  Host vendors  
didn't adopt it, and it languished.  The problem eventually got  
solved with HSRP and its clone, VRRP.


This doesn't resolve the real underlying problem: Ethernet is  
inherently insecure.  MAC addresses can be forged, protocols (ARP,  
ND) can be forged and at this point, there's not much that we can do  
about it.  Architecturally, we need authentication over each and  
every control plane packet sent.  Getting there without invoking the  
full complexity of a public key infrastructure is still an unsolved  
problem, AFAIK.


Tony

Re: v6 subnet size for DSL & leased line customers

[Florian Weimer]

* Tim Durack:

> Probably why some vendors support "dhcp snooping" and "private vlans" for
> IPv4 - multiple clients per subnet with isolation.

The isolation is far from perfect because you don't know from which host
the packet actually came. 8-(

Re: v6 subnet size for DSL & leased line customers

[Florian Weimer]

* Leo Bicknell:

> In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch 
> wrote:
>> RA is a shotgun.  All hosts on a segment get the same gateway.  I have 
>> no idea what a host on multiple segments with different gateways would 
>> do.  Hosting environments can get complex thanks to customer
>
> I would like to point out that in IPv4 we have ICMP Router
> Advertisement messages.  I have never seen them used on a production
> network.  I know one of the worries is security, that a compromised host
> could send out advertisements, drawing traffic to it that it can then
> snoop and pass on to the real gateway.

DHCP and ARP face the same issue.  That's why "one host per subnet" is
so appealing.

Re: v6 subnet size for DSL & leased line customers

[Leo Bicknell]

In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote:
> RA is a shotgun.  All hosts on a segment get the same gateway.  I have 
> no idea what a host on multiple segments with different gateways would 
> do.  Hosting environments can get complex thanks to customer

I would like to point out that in IPv4 we have ICMP Router
Advertisement messages.  I have never seen them used on a production
network.  I know one of the worries is security, that a compromised host
could send out advertisements, drawing traffic to it that it can then
snoop and pass on to the real gateway.

Having not looked in great detail, I am unclear if IPv6 has done
something to fix this concern or not.

Is this feature going to get turned off when the first worm comes along
that spoofs RA's

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org


pgpkunR03iHNX.pgp
Description: PGP signature

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> If the ops community doesn't provide enough addresses and a way to use
> them then the vendors will do the same thing they did in v4. It's not
> clear to me where their needs don't coincide in this case.
> 
> there are three legs to the tripod
> 
>   network operator
>   user
>   equipment manufacturer
> 
> They have (or should have) a mutual interest in:
> 
>   Transparent and automatic configuration of devices.
>   The assignment of globally routable addresses to internet
>   connected devices
>   the user having some control over what crosses the boundry
>   between their network and the operators.

Yes, well, that sounds fine, but I think that we've already hashed over
at least some of the pressures on businesses in this thread.  I've
tried to focus on what's in the Subject:, and have mostly ignored other
problems, which would include things such as cellular service, where I
suspect that the service model is such that they'll want to find a way
to allocate users a /128 ...

There is, further, an effect which leads to "equipment mfr" being split
into "netwk equipment mfr" and "cpe equipment mfr", because the CPE guys 
will be trying to build things that'll work for the end user, working
around any brokenness, etc.  The problem space is essentially polarized, 
between network operators who have their own interests, and users who
have theirs.

So, as /engineers/ for the network operators, the question is, what can
we do to encourage/coerce/force the businesses on our side of the 
equation to allocate larger rather than smaller numbers of bits, or find
other solutions?

What could we do to encourage, or better yet, mandate, that an ISP end-
user connection should be allocated a minimum of /56, even if it happens 
to be a cellular service?  ( :-) )

What do we do about corporate environments, or any other environment where
there may be pressure to control topology to avoid "DHCP PD" to devices
added to the network on an ad-hoc basis?

Is it actually an absolutely unquestionable state of affairs that the
smallest autoconfigurable subnet is a /64?  Because if not, there are
options there ...  but of course, that leads down a road where an ISP may
not want to allocate as much as a /64 ...

What parts of this can we tackle through RIR policy?  RFC requirements?
Best practice?  Customer education?  ( :-) )  Other ideas?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

Tony Li wrote:
> Randy's attitude that vendor's are all unequivocally evil

please read what i said, and not what joel, very incorrectly, said what
i said.  then apologize.

randy

Re: v6 subnet size for DSL & leased line customers

[Joel Jaeggli]

Randy Bush wrote:
> Joel Jaeggli wrote:
>> equipment makers (as much as randy hates them)
> 
> excuse?!?!?  that is unjustified and uncalled for.
>
> vendors, like everyone else, will do what is in their best interests.
> as i am an operator, not a vendor, that is often not what is in my best
> interest, marketing literature aside.  i believe it benefits the ops
> community to be honest when the two do not seem to coincide.

If the ops community doesn't provide enough addresses and a way to use
them then the vendors will do the same thing they did in v4. It's not
clear to me where their needs don't coincide in this case.

there are three legs to the tripod

network operator

user

equipment manufacturer

They have (or should have) a mutual interest in:

Transparent and automatic configuration of devices.

The assignment of globally routable addresses to internet
connected devices

the user having some control over what crosses the boundry
between their network and the operators.


> randy
> 

RE: v6 subnet size for DSL & leased line customers

[John van Oppen]

Yep, it is sure little or no maintenance is being performed.   :)


John 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Leigh Porter
Sent: Tuesday, December 25, 2007 4:06 PM
To: Crawford, Scott
Cc: nanog@merit.edu
Subject: Re: v6 subnet size for DSL & leased line customers



LOL.. Yeah, I am on call today - thankfully nothing happened. Anyway, I 
hope you had a peaceful day!

--
Leigh



Crawford, Scott wrote:
> Well, I guess he told you.  :)
>
> Merry Christmas
> Scotte
>
> -Original Message-
> From: "Jeroen Massar" <[EMAIL PROTECTED]>
> To: "Leigh Porter" <[EMAIL PROTECTED]>
> Cc: nanog@merit.edu
> Sent: 07/12/25 11:48 AM
> Subject: Re: v6 subnet size for DSL & leased line customers
>
> Leigh Porter wrote:
>   
>> Wow, is this what you folks do at Christmas ?
>> 
>
> Clearly you yourself are affectionate about this thing called
Christmas,
> if you are so affectionate about it, then why are you making silly
> comments which do not contribute at all to the topic at hand?
> Must be very boring that Christmas of yours.
>
>
> On a more operational topic: even during Christmas (that Coca Cola
> induced commercialism party that gets attributed to some religion),
> people are using the Internet, and stuff breaks on the Internet, as
such
> there will always be people who have to work on days like this.
>
> Greets,
>  Jeroen
>   

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

Joel Jaeggli wrote:
> equipment makers (as much as randy hates them)

excuse?!?!?  that is unjustified and uncalled for.

vendors, like everyone else, will do what is in their best interests.
as i am an operator, not a vendor, that is often not what is in my best
interest, marketing literature aside.  i believe it benefits the ops
community to be honest when the two do not seem to coincide.

randy

Re: v6 subnet size for DSL & leased line customers

[Stephen Sprunk]

Thus spake <[EMAIL PROTECTED]>

In places where you need tighter control over the usage of various
gateways on a common L2 segment, VRRP probably makes more
sense.  However, as things currently stand, that means static routing
configuration on the host since for reasons passing understanding,
DHCP6 specifically won't do gateway assignment.


For those of us with lots of IPv4 customers dependent on DHCP, it
would be good to know more detail about this point. What is the
problem, and are there plans to do anything about it in DHCPv6?


For most hosts, there is no need for anything like VRRP or getting a default 
gateway via DHCP in v6 because all hosts are required to implement RA/RS. 
The vast majority of hosts either have one default gateway or two-plus 
equivalent ones, so that works fine.  For hosts with multiple gateways that 
are unequal, VRRP+DHCP doesn't solve the problem any better than RA/RS; you 
have to fiddle with the hosts' routing tables to get things set up right.


S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking 

Re: v6 subnet size for DSL & leased line customers

[Leigh Porter]

LOL.. Yeah, I am on call today - thankfully nothing happened. Anyway, I 
hope you had a peaceful day!


--
Leigh



Crawford, Scott wrote:

Well, I guess he told you.  :)

Merry Christmas
Scotte

-Original Message-
From: "Jeroen Massar" <[EMAIL PROTECTED]>
To: "Leigh Porter" <[EMAIL PROTECTED]>
Cc: nanog@merit.edu
Sent: 07/12/25 11:48 AM
Subject: Re: v6 subnet size for DSL & leased line customers

Leigh Porter wrote:
  

Wow, is this what you folks do at Christmas ?



Clearly you yourself are affectionate about this thing called Christmas,
if you are so affectionate about it, then why are you making silly
comments which do not contribute at all to the topic at hand?
Must be very boring that Christmas of yours.


On a more operational topic: even during Christmas (that Coca Cola
induced commercialism party that gets attributed to some religion),
people are using the Internet, and stuff breaks on the Internet, as such
there will always be people who have to work on days like this.

Greets,
 Jeroen
  

Re: v6 subnet size for DSL & leased line customers

[Jeroen Massar]

Leigh Porter wrote:
> 
> 
> Wow, is this what you folks do at Christmas ?

Clearly you yourself are affectionate about this thing called Christmas,
if you are so affectionate about it, then why are you making silly
comments which do not contribute at all to the topic at hand?
Must be very boring that Christmas of yours.


On a more operational topic: even during Christmas (that Coca Cola
induced commercialism party that gets attributed to some religion),
people are using the Internet, and stuff breaks on the Internet, as such
there will always be people who have to work on days like this.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature

Re: v6 subnet size for DSL & leased line customers

[Leigh Porter]

Wow, is this what you folks do at Christmas ?

--
Leigh


Joe Greco wrote:

Right... Let's look at this in detail:

/48 per customer == 65,536 customers at $2,250 == $0.03433/customer
/56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer

So, total savings per customer is $0.0342/customer _IF_ you have
16,777,216 customers.  On the other hand, sir, for those customers
who need more than 256 subnets, we're running the risk of having
to assign them multiple noncontiguous prefixes. 



Okay, here's a problem.  You keep making these statements which bear no
resemblance to the real world.

If I "need more than 256 subnets", and I approach my ISP to ask for such,
there are at least two obvious answers which are incredibly more likely
than any risk of "assign[ing] them[me] multiple noncontiguous prefixes."

Answer 1: "We don't provide more space on your Cableco Cable Modem
Service.  If you would like, we do offer Cableco Business Class Service."

Answer 2: "We can assign you a larger prefix, however, you'll need to
power cycle the cable modem and your addresses will change."

Remember, this is residential broadband.  Saying /no/ is fairly common
(in the same way that I can't get custom PTR DNS for a static IP address
on a resi connection with many service providers.)

  

Although the cost
of doing so is not readily apparent, each router has a limit to the  
number

of prefixes that can be contained in the routing table.



Yeah, well, I'm not impressed.  As an operator community, we've been so
good about getting our own affairs in order there.

  

The cost of
upgrading all of our routers later probably far exceeds the $0.03
per customer that we would save.  Really, in general, I think that
the place to look for per-customer savings opportunities would
be in places where we have a potential recovery greater than
$0.03 per customer.



How about /not/ upgrading all of your routers and keeping the "$0.03
per customer"?

  
This discussion is getting really silly; the fact of the matter is  
that

this /is/ going to happen.  To pretend that it isn't is simply naive.

  
How high are your transit&equipment bills again, and how are you  
exactly

charging your customers? ah, not by bandwidth usage, very logical!


Perhaps end-user ISP's don't charge by bandwidth usage...
  

True, but, they don't, generally, charge by the address, either.
Usually, they charge by the month.  If you can't cover $0.03/year/ 
customer

for address space in your monthly fees, then, raise your monthly
fee by $0.05.  I'm betting your customers won't care.



Customers at the low end of the spectrum do in fact care, and my guess
would be that they'd rather save the nickel than get extra address space
that only 1 in 1,000 of them might ever get around to using.

  
As an enduser I would love to pay the little fee for IP space that  
the

LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
bandwidth that I am using + a little margin so that they ISP also  
earns

some bucks and can do writeoffs on equipment and personnel.

Sure, but that's mostly fantasyland.  The average ISP is going to  
want to
monetize the variables.  You want more bandwidth, you pay more.  You  
want

more IP's, you pay more.  This is one of the reasons some of us are
concerned about how IPv6 will /actually/ be deployed ...  quite  
frankly,

I would bet that it's a whole lot more likely that an end-user gets
assigned a /64 than a /48 as the basic class of service, and charge  
for

additional bits.  If we are lucky, we might be able to s/64/56/.

I mean, yeah, it'd be great if we could mandate /48 ...  but I just  
can't

see it as likely to happen.
  
I'm betting that competition will drive the boundary left without  
additional
fees.  After all, if you're only willing to dole out /64s and your  
competitor is
handing out /56 for the same price, then all the customers that want  
multiple
subnets are going to go to your competitor.  The ones that want /48s  
will

find a competitor that offers that.



Ah!  That's good.  Now we're making some progress.

The first question most businesses have when they're spending money is
"how much is it."  Not "how much is it on a per-customer basis."  If I
go and ask for a new $2000 server so that I can put up some neat new
thing, such as a reverse-traceroute webserver, the idea is that I should
need to justify why it can't be done on an existing webserver.  Maybe it
can, but maybe it can't (let's say because it'll connect out to our
routers and the security risk warrants a separate server).  The fact
that it might only cost a penny per month per customer is irrelevant to
the higher-level analysis.

In the same way, if an ISP can avoid spending money, there are almost
certainly some who will do so.  Since the average customer is likely to
be more than adequately served by 256 subnets for the foreseeable future,
there will undoubtedly be some that allo

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> Right... Let's look at this in detail:
> 
> /48 per customer == 65,536 customers at $2,250 == $0.03433/customer
> /56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer
> 
> So, total savings per customer is $0.0342/customer _IF_ you have
> 16,777,216 customers.  On the other hand, sir, for those customers
> who need more than 256 subnets, we're running the risk of having
> to assign them multiple noncontiguous prefixes. 

Okay, here's a problem.  You keep making these statements which bear no
resemblance to the real world.

If I "need more than 256 subnets", and I approach my ISP to ask for such,
there are at least two obvious answers which are incredibly more likely
than any risk of "assign[ing] them[me] multiple noncontiguous prefixes."

Answer 1: "We don't provide more space on your Cableco Cable Modem
Service.  If you would like, we do offer Cableco Business Class Service."

Answer 2: "We can assign you a larger prefix, however, you'll need to
power cycle the cable modem and your addresses will change."

Remember, this is residential broadband.  Saying /no/ is fairly common
(in the same way that I can't get custom PTR DNS for a static IP address
on a resi connection with many service providers.)

> Although the cost
> of doing so is not readily apparent, each router has a limit to the  
> number
> of prefixes that can be contained in the routing table.

Yeah, well, I'm not impressed.  As an operator community, we've been so
good about getting our own affairs in order there.

> The cost of
> upgrading all of our routers later probably far exceeds the $0.03
> per customer that we would save.  Really, in general, I think that
> the place to look for per-customer savings opportunities would
> be in places where we have a potential recovery greater than
> $0.03 per customer.

How about /not/ upgrading all of your routers and keeping the "$0.03
per customer"?

> > This discussion is getting really silly; the fact of the matter is  
> > that
> > this /is/ going to happen.  To pretend that it isn't is simply naive.
> >
> >> How high are your transit&equipment bills again, and how are you  
> >> exactly
> >> charging your customers? ah, not by bandwidth usage, very logical!
> >
> > Perhaps end-user ISP's don't charge by bandwidth usage...
>
> True, but, they don't, generally, charge by the address, either.
> Usually, they charge by the month.  If you can't cover $0.03/year/ 
> customer
> for address space in your monthly fees, then, raise your monthly
> fee by $0.05.  I'm betting your customers won't care.

Customers at the low end of the spectrum do in fact care, and my guess
would be that they'd rather save the nickel than get extra address space
that only 1 in 1,000 of them might ever get around to using.

> >> As an enduser I would love to pay the little fee for IP space that  
> >> the
> >> LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
> >> bandwidth that I am using + a little margin so that they ISP also  
> >> earns
> >> some bucks and can do writeoffs on equipment and personnel.
> >
> > Sure, but that's mostly fantasyland.  The average ISP is going to  
> > want to
> > monetize the variables.  You want more bandwidth, you pay more.  You  
> > want
> > more IP's, you pay more.  This is one of the reasons some of us are
> > concerned about how IPv6 will /actually/ be deployed ...  quite  
> > frankly,
> > I would bet that it's a whole lot more likely that an end-user gets
> > assigned a /64 than a /48 as the basic class of service, and charge  
> > for
> > additional bits.  If we are lucky, we might be able to s/64/56/.
> >
> > I mean, yeah, it'd be great if we could mandate /48 ...  but I just  
> > can't
> > see it as likely to happen.
>
> I'm betting that competition will drive the boundary left without  
> additional
> fees.  After all, if you're only willing to dole out /64s and your  
> competitor is
> handing out /56 for the same price, then all the customers that want  
> multiple
> subnets are going to go to your competitor.  The ones that want /48s  
> will
> find a competitor that offers that.

Ah!  That's good.  Now we're making some progress.

The first question most businesses have when they're spending money is
"how much is it."  Not "how much is it on a per-customer basis."  If I
go and ask for a new $2000 server so that I can put up some neat new
thing, such as a reverse-traceroute webserver, the idea is that I should
need to justify why it can't be done on an existing webserver.  Maybe it
can, but maybe it can't (let's say because it'll connect out to our
routers and the security risk warrants a separate server).  The fact
that it might only cost a penny per month per customer is irrelevant to
the higher-level analysis.

In the same way, if an ISP can avoid spending money, there are almost
certainly some who will do so.  Since the average customer is likely to
be more than adequately served by 256 subnets for the foreseeable future,
there will un

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 25 dec 2007, at 6:43, Kevin Loch wrote:

With router advertisements present you don't need VRRP because you  
have dead neighbor detection.



And that helps the hosts on the same l2 segment that need different
gateways how?  Or hosts with access to multiple l2 segments with
different gateways?


In my opinion, having hosts with different default gateways on the  
same LAN is not the most desirable way to build a network. If you have  
hosts with multiple interfaces and you want to set routes on those  
host for stuff that's reachable through a router on the interface  
that's not talking to the default router, then I agree VRRP would be  
useful. But again, I would probably try to avoid a setup like that.  
(Not saying that I'm dead set against the availability of VRRP for  
IPv6, though.)


On 25 dec 2007, at 11:24, [EMAIL PROTECTED] wrote:


since for reasons passing understanding, DHCP6 specifically won't do
gateway assignment.


For those of us with lots of IPv4 customers dependent on DHCP, it  
would

be good to know more detail about this point. What is the problem, and
are there plans to do anything about it in DHCPv6?


It looks like many people working on DHCP for IPv6 favor a model where  
there is a separation of tasks between RAs and DHCPv6. So one does one  
thing, the other does something else. No overlap. Now I don't  
subscribe to that philosophy, because I want my hosts to learn their  
DNS servers from RAs (and finally we have RFC 5006!) but in this case  
I agree: there is no good way to make sure that what a DHCP server  
says is actually working, while a router advertising its own presence  
obviously does that.


Address configuration and everything associated with it is the place  
where IPv4 and IPv6 are really different, so don't try to copy  
existing stuff in this area to IPv6 blindly, more often than not  
that's not the most optimal approach.


There are actually some people asking for default gateways in DHCPv6.  
If this happens, it should be such that a DHCPv6 server can tell you  
which of the available gateways to prefer, but nothing stronger than  
that.

Re: v6 subnet size for DSL & leased line customers

[Paul Jakma]

On Mon, 24 Dec 2007, Jeroen Massar wrote:


For some magic reasons though(*), it seems to be completely ludacrist to
do it this way, even though it would make the bill very clear and it
would charge the right amount for the right things and not some
arbitrary number for some other arbitrary things



(* = then again I don't have an mba or something like that so I prolly
miss out an all kinds of important factors why people have to make
it so complex)


I don't have an MBA either. However I will note that many european 
airlines itemise their bills such that external costs (like taxes, 
shared-resource fees, etc) are seperated out.


This practice seems particularly popular with low-cost airlines, as 
it allows them to advertise rock-bottom fares, where that fare is 
just the cost they have control of.


So there seems to be real-world precedent for your proposal, in one 
of the tightest-margin and most cost-sensitive industries around.


Prettige kerstdagen!

regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
If you look good and dress well, you don't need a purpose in life.
-- Robert Pante, fashion consultant

Re: v6 subnet size for DSL & leased line customers

[sthaug]

> In places where you need tighter control over the usage of various  
> gateways
> on a common L2 segment, VRRP probably makes more sense.  However,
> as things currently stand, that means static routing configuration on  
> the host
> since for reasons passing understanding, DHCP6 specifically won't do
> gateway assignment.

For those of us with lots of IPv4 customers dependent on DHCP, it would
be good to know more detail about this point. What is the problem, and
are there plans to do anything about it in DHCPv6?

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

Re: v6 subnet size for DSL & leased line customers

[Owen DeLong]

On Dec 24, 2007, at 9:43 PM, Kevin Loch wrote:



Iljitsch van Beijnum wrote:

On 24 dec 2007, at 20:00, Kevin Loch wrote:

RA/Autoconf won't work at all for some folks with deployed server
infra,
That's just IPv4 uptightness. As long as you don't change your MAC  
address you'll get the same IPv6 address every time, this works  
fine for servers unless you need a memorable address. BTW, I don't  
know anyone who uses DHCP for their servers.

Hopefully vrrpv6 will work with RA turned completely off.
With router advertisements present you don't need VRRP because you  
have dead neighbor detection.


And that helps the hosts on the same l2 segment that need different
gateways how?  Or hosts with access to multiple l2 segments with
different gateways?

I think the point is that RA and VRRPv6 are not designed to depend on  
each

other in any way.

While you can certainly run both on any given segment, it is hard to  
imagine

many cases where one would want to do so.

In places where all you need is to know a valid gateway that can do  
the right
thing with your packets, RA is probably the right solution.  This,  
generally,
turns out to be the vast majority of LAN segments.  Clearly, RA is  
intended

only for scenarios where a gateway is a gateway is a gateway.

In places where you need tighter control over the usage of various  
gateways

on a common L2 segment, VRRP probably makes more sense.  However,
as things currently stand, that means static routing configuration on  
the host

since for reasons passing understanding, DHCP6 specifically won't do
gateway assignment.

I don't know the state of the current VRRP6 draft or protocol, but, I  
can't
imagine what would be left in VRRP6 if it couldn't be statically  
configured
without RA.  If that's the case, then, what would it possibly do,  
exactly, that

would be different from RA without VRRP?

Owen

Re: v6 subnet size for DSL & leased line customers

[Kevin Loch]

Iljitsch van Beijnum wrote:

On 24 dec 2007, at 20:00, Kevin Loch wrote:


RA/Autoconf won't work at all for some folks with deployed server
infra,


That's just IPv4 uptightness. As long as you don't change your MAC 
address you'll get the same IPv6 address every time, this works fine for 
servers unless you need a memorable address. BTW, I don't know anyone 
who uses DHCP for their servers.



Hopefully vrrpv6 will work with RA turned completely off.


With router advertisements present you don't need VRRP because you have 
dead neighbor detection.


And that helps the hosts on the same l2 segment that need different
gateways how?  Or hosts with access to multiple l2 segments with
different gateways?

RA is a shotgun.  All hosts on a segment get the same gateway.  I have 
no idea what a host on multiple segments with different gateways would 
do.  Hosting environments can get complex thanks to customer

requirements and baggage from previous migrations. Load balancer and VPN
configurations are common culprits but there are also cases where
servers need different gateways for routing policy reasons. All of this
is easily accommodated with static gateways and the redundancy provided
by vrrpv4.  Please don't take that away from us.  Migration to v6 will
be difficult enough without subtracting functionality from our existing
tools.

Other than that I look forward to seeing what wonderful things we can
do with RA to simplify things in cases where shotgun == ok.

- Kevin

Re: v6 subnet size for DSL & leased line customers

[Mohacsi Janos]

On Sun, 23 Dec 2007, Randy Bush wrote:



Mohacsi Janos wrote:

There plenty of organisation who has a dedicated team/person for
network management (routers, switches etc.), while another
team/person for system management (dhcp, servers etc.). So
configuring DHCPv6 requires cooperation which takes time, but users
are complaining




so, what problems are there with dhcpv6 that differ from those we have
experienced with dchpv4?  what would be good to know before trying to
deploy it?

do organizations you know prefer autoconf or dhcpv6?  and why?


Actually we are using stateless form of DHCPv6 to announce DNS servers 
with autoconf + static address comfiguration for servers. This is 
satisfactory for a small organisation like us (less than 40 persons). We 
are testing DHCPv6 also. For a larger organisation (>1000 computer) I will 
ask my colleagues about their DHCPv6 experiences


Best Regards,
Janos Mohacsi

Re: v6 subnet size for DSL & leased line customers

[Iljitsch van Beijnum]

On 24 dec 2007, at 20:00, Kevin Loch wrote:


RA/Autoconf won't work at all for some folks with deployed server
infra,


That's just IPv4 uptightness. As long as you don't change your MAC  
address you'll get the same IPv6 address every time, this works fine  
for servers unless you need a memorable address. BTW, I don't know  
anyone who uses DHCP for their servers.



Hopefully vrrpv6 will work with RA turned completely off.


With router advertisements present you don't need VRRP because you  
have dead neighbor detection.

Re: v6 subnet size for DSL & leased line customers

[Deepak Jain]

Christopher Morrow wrote:

On Dec 22, 2007 12:23 PM, Ross Vandegrift <[EMAIL PROTECTED]> wrote:

On Fri, Dec 21, 2007 at 01:33:15PM -0500, Deepak Jain wrote:

For example... Within one's own network (or subnet if you will) we can
absorb all the concepts of V4 today and have lots of space available.
For example... for the DMZ of a business... Why not give them 6 bits
(/122?) are we anticipating topology differences UPSTREAM from the
customers that can take advantage of subnet differences between /64 and
/56 ?

I am confused on this point as well.  IPv6 documents seem to assume
that because auto-discovery on a LAN uses a /64, you always have to
use a /64 global-scope subnet.  I don't see any technical issues that
require this though.  ICMPv6 is capable of passing info on prefixes of
any length -  prefix length is a plain old 8bit field.



Uhm, so sure the spec might be able to do something different than /64
but most equipment I've used only does auto-conf if the prefix is a
/64 :( Somewhere along the path to ipng we got reverted to classful
addressing again :(



I think this is the point I was trying to make. Just because we have "so 
many bits" now... why does the equipment/software need to get "stupider" 
again? Are we going to have an IPv6 CIDR initiative again (15 years from 
now) to recover all of that wasted space from "early" allocations)..


Merry Christmas, and junk.

Deepak

Re: v6 subnet size for DSL & leased line customers

[Kevin Loch]

Christopher Morrow wrote:


RA/Autoconf won't work at all for some folks with deployed server
infra, all they want is a method to get a static addr on a box and
route properly. Perhaps RA gets them the 'route properly' part easily
enough but I can imagine places where that is even turned off.


I think it would be great to  be able to do hybrids with RA for other 
situations where a shotgun approach is ok but I do not think we will 
want to use that in server environments.  Hopefully vrrpv6 will work

with RA turned completely off.

- Kevin

Re: v6 subnet size for DSL & leased line customers

[Joe Maimon]

Scott Weeks wrote:




Disclaimer:  I'm still very much an IPv6 wussie...  :-)

-
But even in 2000 the policy was and still is:
 /128 for really a single device
 /64  if you know for sure that only one single subnet will
  ever be allocated.
 /48  for every other case (smart bet, should be used per default)
--

I work on a network with 100K+ DSL folks and 200+ leased line customers, plus 
some other stuff.  The leased line customers are increasing dramatically.  I 
should plan for a /64 for every DSL customer and a /48 for every leased line 
customer I expect over the next 5-7 years?

scott


Same disclaimer as above. But perhaps thats a benefit, allowing the 
landscape forest view instead of the tree one.


Seems like everything good and desirable in ipv6 was backported to ipv4, 
including router advertisements (which nobody uses, since DHCP [yes dhcp 
can/could be made redundant] is far far preferred, even by SOHO vendors).


All except the 4 x bitspace.

If it hasnt been backported after all this time, its likely either 
undoable or unusable.


Since its quite likely that a minimum 50 year lifetime for ipv4 looks to 
be in the cards, judging by bitspace, ipv6 should be engineered for 200 
(or 50 to the 4th which makes 125000).


One would suppose that the way to do this is to do as much as is 
neccessary to comfortably move the world onto it AND NO MORE. We are not 
prophets. We dont even know how many prefixes the average router will be 
able to handle in 10 years (considering that a maxed out pc-as-a-router 
can handle millions more than the nice expensive 7600), let alone 50.


So the first thing we do is:

Make it as big for ISP's as ipv4 was for end users, by assigning /32 
prefixes, minus all the special purpose carvings.


To make things simple, a 4 byte AS should come with a /32.

Brilliant. We have forward ported ipv4 scalability onto ipv6.

For what? So that end users can have nanotech networks? It goes without 
saying that I will want my nanotech network(s) firewalled (and natted 
for good measure).


Autoconfiguration doesnt require 64 bits. We have autoconfig for ipv4, 
it appears to only need 16.


As stated, we dont want people to be taking their /64's with them as 
they change ISP's, so imbuing all this uniqueness and matching it with 
their global id's and telephone numbers is just asking for trouble.


Unless the whole world becomes an ISP. Presto, address shortage unless 
massive depopulation occurs over the next couple hundred years.


We should not pretend to be building an allocation structure that will 
not simultaneously satisify uniqueness, portability and scalability for 
the next hundred years or so when we clearly are not.


Whats the current state with PI in ipv6? How often will it change?

We could have reserved 90% of the first 32 bits, use the next 32 bits to 
assign to ISP's /64 bits, and allow the ISP's to assign an internet 
worth of customer their own internet.


Tiered routing? Geo-location routing? All easily made available with 
another bit or two from the first /32.


Oh and the whole protocol is still useless, since proper connectivity 
to the ipv4 network without an ipv4 stack seems to be somewhat non 
standard. Obviously, nobody rolling out ipv6 due to address shortage is 
going to tolerate that, and interop strategies will be used, standard or 
not.


Expect the interop strategy to be the one with the lowest network 
resistance. Thats nat.


IPv6 is a textbook second system syndrome. We could have all been on it 
already without the dozens of super-freighters attached to the 128bit 
tugboat.


Joe

Re: v6 subnet size for DSL & leased line customers

[Joel Jaeggli]

Joe Greco wrote:
>> It's likely that the device may choose to nat when they cannot obtain a
>> prefix... pd might be desirable but if you can't then the alternative is
>> easy.
> 
> I thought we were all trying to discourage NAT in IPv6. 

You/we are... Which is why you really need PD, and cpe needs to be able
to hand out /64s on request to downstream devices. Not surprisingly that
will drive subnetting in the home. presently, plugging in more
gateway/router devices results in multiple layers of nat and huge
amounts of unnecessary complexity in the home network.

> Clearly, NAT
> solves the problem ... while introducing 1000 new ones.  :-/

Sure, we don't have a reasonable mechanism for ipv4 devices to pull
address space out of thin air. We do have one in ipv6. This is a problem
that equipment makers (as much as randy hates them) will have to
address. It doesn't take much imagination to figure out how they will
address it given a lack of alternatives.

> ... JG

Re: v6 subnet size for DSL & leased line customers

[Brandon Butterworth]

> I thought we were all trying to discourage NAT in IPv6.  Clearly, NAT
> solves the problem ... while introducing 1000 new ones.  :-/

Clearly some have been trying to discourage NAT in IPv6
ensuring there'll be a 1000 problems if anyone tries.

> I mean, yeah, it'd be great if we could mandate /48 ...  but I just can't
> see it as likely to happen.

If people are supposed to have a /48 then the allocation rules
should say that's what they will get.

It may be xmas but it's not wise to rely on the benevolence of ISPs

brandon

Re: v6 subnet size for DSL & leased line customers

[Owen DeLong]

"Well, you say we need to spend more money every year on address  
space.
Right now we're paying $2,250/year for our /32, and we're able to  
serve
65 thousand customers.  You want us to start paying $4,500/year, but  
Bob

tells me that we're wasting a lot of our current space, and if we were
to begin allocating less space to customers [aside: /56 vs /48],  
that we
could actually serve sixteen million users for the same cash.  Is  
there

a compelling reason that we didn't do that from the outset?"


Right... Let's look at this in detail:

/48 per customer == 65,536 customers at $2,250 == $0.03433/customer
/56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer

So, total savings per customer is $0.0342/customer _IF_ you have
16,777,216 customers.  On the other hand, sir, for those customers
who need more than 256 subnets, we're running the risk of having
to assign them multiple noncontiguous prefixes.  Although the cost
of doing so is not readily apparent, each router has a limit to the  
number

of prefixes that can be contained in the routing table.  The cost of
upgrading all of our routers later probably far exceeds the $0.03
per customer that we would save.  Really, in general, I think that
the place to look for per-customer savings opportunities would
be in places where we have a potential recovery greater than
$0.03 per customer.

This discussion is getting really silly; the fact of the matter is  
that

this /is/ going to happen.  To pretend that it isn't is simply naive.

How high are your transit&equipment bills again, and how are you  
exactly

charging your customers? ah, not by bandwidth usage, very logical!


Perhaps end-user ISP's don't charge by bandwidth usage...


True, but, they don't, generally, charge by the address, either.
Usually, they charge by the month.  If you can't cover $0.03/year/ 
customer

for address space in your monthly fees, then, raise your monthly
fee by $0.05.  I'm betting your customers won't care.

As an enduser I would love to pay the little fee for IP space that  
the

LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
bandwidth that I am using + a little margin so that they ISP also  
earns

some bucks and can do writeoffs on equipment and personnel.


Sure, but that's mostly fantasyland.  The average ISP is going to  
want to
monetize the variables.  You want more bandwidth, you pay more.  You  
want

more IP's, you pay more.  This is one of the reasons some of us are
concerned about how IPv6 will /actually/ be deployed ...  quite  
frankly,

I would bet that it's a whole lot more likely that an end-user gets
assigned a /64 than a /48 as the basic class of service, and charge  
for

additional bits.  If we are lucky, we might be able to s/64/56/.

I mean, yeah, it'd be great if we could mandate /48 ...  but I just  
can't

see it as likely to happen.

I'm betting that competition will drive the boundary left without  
additional
fees.  After all, if you're only willing to dole out /64s and your  
competitor is
handing out /56 for the same price, then all the customers that want  
multiple
subnets are going to go to your competitor.  The ones that want /48s  
will

find a competitor that offers that.

That's how the real world works.  I remember having to repeatedly  
involve

senior management in rejecting requests for /24s from customers who
could not justify them because our sales people at Exodus kept promising
them.  The sales people continuously suggested that our competitors
were offering everyone /24s and that they had to do that to win the  
deals.


OTOH, "Raw bandwidth communications" seems to want to charge bandwidth
utilization not actually based on the bandwidth utilized, but, the  
number of

IP addresses routed.  They are not my ISP for that reason.

Different providers have different business models.  Consumers will
find the provider with the business model that best fits their needs.
That's the way it works in the real world.


So, the point is, as engineers, let's not be completely naive.  Yes,  
we
/want/ end-users to receive a /56, maybe even a /48, but as an  
engineer,
I'm going to assume something more pessimistic.  If I'm a device  
designer,
I can safely do that, because if I don't assume that a PD is going  
to be
available and plan accordingly, then my device is going to work in  
both

cases, while the device someone who has relied on PD is going to break
when it isn't available.


Assuming that PD is available is naive.  However, assuming it is not is
equally naive.  The device must be able to function in both  
circumstances
if possible, or, should handle the case where it can't function in a  
graceful

and informative manner.

Owen

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> Joe Greco wrote:
> [..]
> > Okay, here, let me make it reaaally simple.
> 
> Yes, indeed lets make it reaaally simple for you:
> 
> > If your ISP has been delegated a /48 (admittedly unlikely, but possible=
> )
> > for $1,250/year, and they assign you a /56, their cost to provide that
> > space is ~$5.  They can have 256 such customers.
> 
> Fortunately ISP's get their space per /32 and up based on how much they
> can justify, which is the amount of customers they have.
> 
> As such for a /32 single /48 is only (x / 65k) =3D like 20 cents or so?
> And if you are running your business properly you will have more clients
> and the price will only go down and down and down.
>
> Really (or should I write "reaaally" to add force?) if you
> as an ISP are unable to pay the RIR fees for that little bit of address
> space, then you definitely have bigger problems as you won't be able to
> pay the other bills either.

There's a difference between "unable to pay the RIR fees" and "do not deem
any business value in spending the money."  Engineers typically feel that
businesses should be ready and willing to spend more money for reasons that
the average business person won't care about.

Pretend I'm your CFO.  Explain the value proposition to me.  Here's the
(slightly abbreviated) conversation.

"Well, you say we need to spend more money every year on address space.
Right now we're paying $2,250/year for our /32, and we're able to serve
65 thousand customers.  You want us to start paying $4,500/year, but Bob
tells me that we're wasting a lot of our current space, and if we were 
to begin allocating less space to customers [aside: /56 vs /48], that we
could actually serve sixteen million users for the same cash.  Is there
a compelling reason that we didn't do that from the outset?"

This discussion is getting really silly; the fact of the matter is that
this /is/ going to happen.  To pretend that it isn't is simply naive.

> How high are your transit&equipment bills again, and how are you exactly
> charging your customers? ah, not by bandwidth usage, very logical!

Perhaps end-user ISP's don't charge by bandwidth usage...

> As an enduser I would love to pay the little fee for IP space that the
> LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
> bandwidth that I am using + a little margin so that they ISP also earns
> some bucks and can do writeoffs on equipment and personnel.

Sure, but that's mostly fantasyland.  The average ISP is going to want to
monetize the variables.  You want more bandwidth, you pay more.  You want
more IP's, you pay more.  This is one of the reasons some of us are 
concerned about how IPv6 will /actually/ be deployed ...  quite frankly, 
I would bet that it's a whole lot more likely that an end-user gets 
assigned a /64 than a /48 as the basic class of service, and charge for 
additional bits.  If we are lucky, we might be able to s/64/56/.

I mean, yeah, it'd be great if we could mandate /48 ...  but I just can't
see it as likely to happen.

> For some magic reasons though(*), it seems to be completely ludacrist to
> do it this way, even though it would make the bill very clear and it
> would charge the right amount for the right things and not some
> arbitrary number for some other arbitrary things and then later
> complaining that people use too much bandwidth because they use
> bittorrent and other such things. For the cable folks: make upstream
> bandwidth more pricey per class than downstream, problem of
> heavy-uploaders solved as they get charged.

Sure, but that's how the real world works.  The input from engineering
folks is only one small variable in the overall scheme of things.  It is
a /mistake/ to assume that cost-recovery must be done on a direct basis.
There's a huge amount of business value in being able to say "unlimited(*)
Internet service for $30/mo!"  The current offerings in many places should
outline this clearly.

So, the point is, as engineers, let's not be completely naive.  Yes, we
/want/ end-users to receive a /56, maybe even a /48, but as an engineer,
I'm going to assume something more pessimistic.  If I'm a device designer,
I can safely do that, because if I don't assume that a PD is going to be 
available and plan accordingly, then my device is going to work in both 
cases, while the device someone who has relied on PD is going to break 
when it isn't available.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> It's likely that the device may choose to nat when they cannot obtain a
> prefix... pd might be desirable but if you can't then the alternative is
> easy.

I thought we were all trying to discourage NAT in IPv6.  Clearly, NAT
solves the problem ... while introducing 1000 new ones.  :-/

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Trent Lloyd]

Hi Jeroen,

On 24/12/2007, at 6:07 PM, Jeroen Massar wrote:


Joe Greco wrote:
[..]

Okay, here, let me make it reaaally simple.


Yes, indeed lets make it reaaally simple for you:

If your ISP has been delegated a /48 (admittedly unlikely, but  
possible)
for $1,250/year, and they assign you a /56, their cost to provide  
that

space is ~$5.  They can have 256 such customers.







How high are your transit&equipment bills again, and how are you  
exactly

charging your customers? ah, not by bandwidth usage, very logical!



Not my bandwidth usage? Ha. Ha. Haha. Ha.

Fortunately a /32 allocation was free from APNIC with our existing  
membership tier.


Regards,
Trent
Australia

Re: v6 subnet size for DSL & leased line customers

[Jeroen Massar]

Joe Greco wrote:
[..]
> Okay, here, let me make it reaaally simple.

Yes, indeed lets make it reaaally simple for you:

> If your ISP has been delegated a /48 (admittedly unlikely, but possible)
> for $1,250/year, and they assign you a /56, their cost to provide that
> space is ~$5.  They can have 256 such customers.

Fortunately ISP's get their space per /32 and up based on how much they
can justify, which is the amount of customers they have.

As such for a /32 single /48 is only (x / 65k) = like 20 cents or so?
And if you are running your business properly you will have more clients
and the price will only go down and down and down.

Really (or should I write "reaaally" to add force?) if you
as an ISP are unable to pay the RIR fees for that little bit of address
space, then you definitely have bigger problems as you won't be able to
pay the other bills either.

How high are your transit&equipment bills again, and how are you exactly
charging your customers? ah, not by bandwidth usage, very logical!

As an enduser I would love to pay the little fee for IP space that the
LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
bandwidth that I am using + a little margin so that they ISP also earns
some bucks and can do writeoffs on equipment and personnel.

For some magic reasons though(*), it seems to be completely ludacrist to
do it this way, even though it would make the bill very clear and it
would charge the right amount for the right things and not some
arbitrary number for some other arbitrary things and then later
complaining that people use too much bandwidth because they use
bittorrent and other such things. For the cable folks: make upstream
bandwidth more pricey per class than downstream, problem of
heavy-uploaders solved as they get charged.

Greets,
 Jeroen

(* = then again I don't have an mba or something like that so I prolly
 miss out an all kinds of important factors why people have to make
 it so complex)



signature.asc
Description: OpenPGP digital signature

Re: v6 subnet size for DSL & leased line customers

[Joel Jaeggli]

Joe Greco wrote:
>> There is a huge detent at /48, but there's a certain amount of guidance
>> that can only be derived from operational experience. It's not clear to
>> me why /56 would be unacceptable, particularly if you're delegating them
>> to a device that already has a /64. Are one's customers attached via
>> point-to-point links, or do they sit on shared broadcast domain where
>> their cpe is receiving a /128 and requesting pd from the outset?
>>
>> When someone plugs an apple airport into a segment of the corporate lan
>> should it be be able to request pd under those circumstances as well?
>> how is that case different than plugging it in on a residential connection?
>>
>> These are issues providers can and should grapple with. 
> 
> More likely, at least some of them are fairly naive questions.
> 
> For example, /experience/ tells us that corporate LAN policies are often
> implemented without regard to what "we", as Internet engineers, would
> prefer, so I can guarantee you with a 100% certainty that there will be
> at least some networks, and more than likely many networks, where you
> will not be able to simply request a prefix delegation and have that work
> the way you'd like.  There will always be some ISP who has delegated, or
> some end site who has received, a "far too close to being just large
> enough" allocation, and so even if we assume that every router vendor
> and IPv6 implementation from here to eternity has no knobs to disable
> prefix delegation, simple prefix exhaustion within an allocation will be 
> a problem.  All the screams of "but they should have been allocated more"
> will do nothing to change this.
> 
> Further, if we consider, for a moment, a world where prefix delegation is
> the only method of adding something like an Apple Airport to an existing
> network, this is potentially encouraging the burning of /64's for the
> addition of a network with perhaps a single client.  That's perfectly fine,
> /as long as/ networks are allocated sufficient resources.  This merely
> means that from a fairly pessimistic viewpoint, IPv6 is actually a 64-bit
> address space for purposes of determining how much address space is
> required.
> 
> So, from the point of view of someone manufacturing devices to attach to
> IPv6 networks, I have some options.
> 
> I can:
> 
> 1) Assume that DHCP PD is going to work, and that the end user will have
>a prefix to delegate, which might be valid or it might not.  This leaves
>me in the position of having to figure out a backup strategy, because I
>do not want users returning my device to Best Buy because "it don't
>work."  The backup strategy is bridging.
> 
> 2) Assume that DHCP PD is not going to work, and make bridging the default
>strategy.  DHCP PD can optionally be a configurable thing, or autodetect,
>or whatever, but it will not be mandatory.
> 
> I am being facetious here, of course, since only one of those is really
> viable in the market.  Anyone who thinks otherwise is welcome to explain to
> me what's going to happen in the case where there are no P's to D.

It's likely that the device may choose to nat when they cannot obtain a
prefix... pd might be desirable but if you can't then the alternative is
easy.

The current apple airport bridges v6 while natting ivp4 this is a
perceived boundary problem in some circles and likely will be addressed
in future software revision.

> I will leave the difference between corporate and residential as an exercise
> to the reader; suffice it to say that the answers are rather obvious in the
> same manner.
> 
> ... JG

Re: v6 subnet size for DSL & leased line customers

[Christopher Morrow]

On Dec 23, 2007 8:44 PM, Randy Bush <[EMAIL PROTECTED]> wrote:
> > and trying to keep 50k machines updated with proper resolvers (in the
> > simplest example) is easier with RA than DHCP how?
>
> do you really mean skip RA or all of autoconf?

I think what makes sense is to use the parts of ipv6 that work well,
RA, but blend in what works already well and is folded already into
the enterprise model... dhcpv6.

>
> i want to explore RA(only) + DHCP, to save me from running a routing
> protocol or vsrp to have redundant exits for a LAN.
>

ok, somewhere there's a blend of things that will work for enterprises
and cable/dsl/mso folk. I think that some enterprises don't mind
'random address selection' while they want to pass out info required
(cause like it or not DNS is required) in a sane manner, one that's
even part of their current method.

RA/Autoconf won't work at all for some folks with deployed server
infra, all they want is a method to get a static addr on a box and
route properly. Perhaps RA gets them the 'route properly' part easily
enough but I can imagine places where that is even turned off.

Basically my rant here is that autoconf isn't enough, it's not even a
starting point for enterprise folks who rely on DHCP for all it's
bells + whistles. Taking a giant leap backwards is never going to fly
for them, so wake up and smell the cafe, dhcpv6 needs to be viable,
workable, operable, built-in and well tested.

> randy, about to go off net, heading for a rural onsen & ryokan
>

have fun!

-Chris

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> > MAC address allocations are paid for by the Ethernet chipset/card vendor.
> > 
> > They're not paid for by an ISP, or by any other Ethernet end-user, except
> > as a pass-through, and therefore it's considered a fixed cost.  There are
> > no RIR fees, and there is no justification.  You buy a gizmo with this
> > RJ45 and you get a unique MAC.  This is simple and straightforward.  If
> > you buy one device, you get one MAC.  If you buy a hundred devices, you
> > get one hundred MAC's.  Not 101, not 99.  This wouldn't seem to map well
> > at all onto the IPv6 situation we're discussing.
> 
> How many ISP customers pay RIR fees? Near enough to none, if not none.

Who said anything about ISP customers paying RIR fees?  Although they
certainly do, indirectly.

> I never have when I've been an ISP customer.

(Must be one of those legacy ISP's?)

> Why are you pretending they do? 

I don't recall bringing them into the discussion, BUT...

> I think your taking an end-user perspective when discussing
> ethernet but an RIR fee paying ISP position when discussing IPv6 subnet
> allocations. That's not a valid argument, because you've changed your
> viewpoint on the situation to suit your position.

Oddly enough, I'm one of those rare people who've worked with both ISP's
and OEM's that have been assigned MAC's.  You can think as you wish, and
you're wrong. 

> Anyway, the point I was purely making was that if you can afford to
> spend the bits, because you have them (as you do in Ethernet by design,
> as you do in IPv6 by design, but as you *don't* in IPv4 by design), you
> can spend them on operational convenience for both the RIR paying
> entity *and* the end-user/customer. Unnecessary complexity is
> *unnecessary*, and your customers won't like paying for it if they
> discover you've chosen to create it either on purpose or through
> naivety.

Okay, here, let me make it reaaally simple.

If I am going out and buying an Ethernet card today, the mfr will pay $.NN 
for my MAC address, a cost that is built into the retail cost of the card.
It will never be more or less than $.NN, because the number of MAC
addresses assigned to my card is 1.  Always 1.  Always $.NN.

If I am going out and buying IPv6 service today, the ISP will pay a
variable amount for my address space.  The exact amount is a function of
their own delegation size (you can meander on over to ARIN yourself) and
the size they've delegated to you; and so, FOR PURPOSES OF ILLUSTRATION,
consider this.

If your ISP has been delegated a /48 (admittedly unlikely, but possible)
for $1,250/year, and they assign you a /56, their cost to provide that
space is ~$5.  They can have 256 such customers.

If your ISP has been delegated a /48 (admittedly unlikely, but possible)
for $1,250/year, and they assign you a /48, their cost to provide that
space is ~$1,250.  They can have 1 such customer.

If your ISP has been delegated a /41, for $1,250/year, and they assign
you a /48, their cost to provide that space is ~$10.  They can have 128
such customers.

There is a significant variation in pricing as the parameters are changed.
You do not just magically have free bits in IPv6 by design; the ISP is
paying for those bits.  There will be factors MUCH more real than whether
or not customers "like paying for it if they discover you've chosen to
create [complexity]," because quite frankly, residential end users do not
typically have a clue, and so even if you do tick off 1% who have a clue,
you're still fine.

Now, seriously, just who do you think is paying for the space?  And if
$competitor down the road is charging rock bottom prices for Internet
access, how much money does the ISP really want to throw at extra address
space?  (Do you want me to discuss naivety now?)

And just /how/ is this in any way similar to Ethernet MAC addresses, 
again?  Maybe I'm just too slow and can't see how "fixed cost" ==
"variable cost."  I won't accept any further hand-waving as an answer,
so to continue, please provide solid examples, as I've done.

Perhaps more on-topic, how many IP addresses can dance on the head of 
a /64?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Mon, 24 Dec 2007 09:58:44 +0900
Randy Bush <[EMAIL PROTECTED]> wrote:

> 
> > There's a tendency to move away from (simulated) shared media networks.
> > "One host per subnet" might become the norm.
> 
> and, with multiple addresses per interface, the home user surely _might_
> need a /32.
> 

What prompted you to suggest that? Trolling maybe?

> 
> might does not make right
> 

Neither does being ridiculous. 

> randy


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sun, 23 Dec 2007 19:27:55 -0600 (CST)
Joe Greco <[EMAIL PROTECTED]> wrote:

> > > > I think Ethernet is also another example of the benefits of
> > > > spending/"wasting" address space on operational convenience - who needs
> > > > 46/47 bits for unicast addressing on a single layer 2 network!? If I
> > > > recall correctly from bits and pieces I've read about early Ethernet,
> > > > the very first versions of Ethernet only had 16 bit node addressing.
> > > > They then decided to spend/"waste" bits on addressing to get
> > > > operational convenience - "plug and play" layer 2 networking.
> > > 
> > > The difference is that it doesn't "cost" anything.  There are no RIR fees,
> > > there is no justification.  You don't pay for, or have to justify, your 
> > > Ethernet MAC addresses.
> > > 
> > > With IPv6, there are certain pressures being placed on ISP's not to be
> > > completely wasteful.
> > 
> > I don't think there is that difference at all. MAC address allocations
> > are paid for by the Ethernet chipset/card vendor, and I'm pretty sure
> > they have to justify their usage before they're allowed to buy another
> > block. I understand they're US$1250 an OUI, so something must have
> > happened to prevent somebody buying them all up to hoard them, creating
> > artificial scarcity, and then charging a market sensitive price for
> > them, rather than the flat rate they cost now. That's not really any
> > different to an ISP paying RIR fees, and then indirectly passing those
> > costs onto their customers.
> 
> MAC address allocations are paid for by the Ethernet chipset/card vendor.
> 
> They're not paid for by an ISP, or by any other Ethernet end-user, except
> as a pass-through, and therefore it's considered a fixed cost.  There are
> no RIR fees, and there is no justification.  You buy a gizmo with this
> RJ45 and you get a unique MAC.  This is simple and straightforward.  If
> you buy one device, you get one MAC.  If you buy a hundred devices, you
> get one hundred MAC's.  Not 101, not 99.  This wouldn't seem to map well
> at all onto the IPv6 situation we're discussing.
> 

How many ISP customers pay RIR fees? Near enough to none, if not none.
I never have when I've been an ISP customer. Why are you pretending
they do? I think your taking an end-user perspective when discussing
ethernet but an RIR fee paying ISP position when discussing IPv6 subnet
allocations. That's not a valid argument, because you've changed your viewpoint 
on the situation to suit your position.

Anyway, the point I was purely making was that if you can afford to
spend the bits, because you have them (as you do in Ethernet by design,
as you do in IPv6 by design, but as you *don't* in IPv4 by design), you
can spend them on operational convenience for both the RIR paying
entity *and* the end-user/customer. Unnecessary complexity is
*unnecessary*, and your customers won't like paying for it if they
discover you've chosen to create it either on purpose or through
naivety.

> With an IPv6 prefix, it is all about the prefix size.  Since a larger 
> allocation may cost an ISP more than a smaller allocation, an ISP may 
> decide that they need to charge a customer who is allocated a /48 more 
> than a customer who is allocated a /64.
> 
> I don't pay anyone anything for the use of the MAC address I got on this
> free ethernet card someone gave me, yet it is clearly and unambiguously
> mine (and only mine) to use.  Does that clarify things a bit?
> 
> If you are proposing that RIR's cease the practice of charging different
> amounts for different allocation sizes, please feel free to shepherd that
> through the approvals process, and then I will certainly agree that there
> is no longer a meaningful cost differential for the purposes of this
> discussion.  Otherwise, let's not pretend that they're the same thing, 
> since they're clearly not.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail 
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many apples.


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

> and trying to keep 50k machines updated with proper resolvers (in the
> simplest example) is easier with RA than DHCP how?

do you really mean skip RA or all of autoconf?

i want to explore RA(only) + DHCP, to save me from running a routing
protocol or vsrp to have redundant exits for a LAN.

randy, about to go off net, heading for a rural onsen & ryokan

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> > > I think Ethernet is also another example of the benefits of
> > > spending/"wasting" address space on operational convenience - who needs
> > > 46/47 bits for unicast addressing on a single layer 2 network!? If I
> > > recall correctly from bits and pieces I've read about early Ethernet,
> > > the very first versions of Ethernet only had 16 bit node addressing.
> > > They then decided to spend/"waste" bits on addressing to get
> > > operational convenience - "plug and play" layer 2 networking.
> > 
> > The difference is that it doesn't "cost" anything.  There are no RIR fees,
> > there is no justification.  You don't pay for, or have to justify, your 
> > Ethernet MAC addresses.
> > 
> > With IPv6, there are certain pressures being placed on ISP's not to be
> > completely wasteful.
> 
> I don't think there is that difference at all. MAC address allocations
> are paid for by the Ethernet chipset/card vendor, and I'm pretty sure
> they have to justify their usage before they're allowed to buy another
> block. I understand they're US$1250 an OUI, so something must have
> happened to prevent somebody buying them all up to hoard them, creating
> artificial scarcity, and then charging a market sensitive price for
> them, rather than the flat rate they cost now. That's not really any
> different to an ISP paying RIR fees, and then indirectly passing those
> costs onto their customers.

MAC address allocations are paid for by the Ethernet chipset/card vendor.

They're not paid for by an ISP, or by any other Ethernet end-user, except
as a pass-through, and therefore it's considered a fixed cost.  There are
no RIR fees, and there is no justification.  You buy a gizmo with this
RJ45 and you get a unique MAC.  This is simple and straightforward.  If
you buy one device, you get one MAC.  If you buy a hundred devices, you
get one hundred MAC's.  Not 101, not 99.  This wouldn't seem to map well
at all onto the IPv6 situation we're discussing.

With an IPv6 prefix, it is all about the prefix size.  Since a larger 
allocation may cost an ISP more than a smaller allocation, an ISP may 
decide that they need to charge a customer who is allocated a /48 more 
than a customer who is allocated a /64.

I don't pay anyone anything for the use of the MAC address I got on this
free ethernet card someone gave me, yet it is clearly and unambiguously
mine (and only mine) to use.  Does that clarify things a bit?

If you are proposing that RIR's cease the practice of charging different
amounts for different allocation sizes, please feel free to shepherd that
through the approvals process, and then I will certainly agree that there
is no longer a meaningful cost differential for the purposes of this
discussion.  Otherwise, let's not pretend that they're the same thing, 
since they're clearly not.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

> There's a tendency to move away from (simulated) shared media networks.
> "One host per subnet" might become the norm.

and, with multiple addresses per interface, the home user surely _might_
need a /32.



might does not make right

randy

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sun, 23 Dec 2007 17:26:12 -0600 (CST)
Joe Greco <[EMAIL PROTECTED]> wrote:

> > If operational simplicity of fixed length node addressing is a
> > technical reason, then I think it is a compelling one. If you've ever
> > done any reasonable amount of work with Novell's IPX (or other fixed
> > length node addressing layer 3 protocols (mainly all of them except
> > IPv4!)) you'll know what I mean.
> > 
> > I think Ethernet is also another example of the benefits of
> > spending/"wasting" address space on operational convenience - who needs
> > 46/47 bits for unicast addressing on a single layer 2 network!? If I
> > recall correctly from bits and pieces I've read about early Ethernet,
> > the very first versions of Ethernet only had 16 bit node addressing.
> > They then decided to spend/"waste" bits on addressing to get
> > operational convenience - "plug and play" layer 2 networking.
> 
> The difference is that it doesn't "cost" anything.  There are no RIR fees,
> there is no justification.  You don't pay for, or have to justify, your 
> Ethernet MAC addresses.
> 
> With IPv6, there are certain pressures being placed on ISP's not to be
> completely wasteful.
>

I don't think there is that difference at all. MAC address allocations
are paid for by the Ethernet chipset/card vendor, and I'm pretty sure
they have to justify their usage before they're allowed to buy another
block. I understand they're US$1250 an OUI, so something must have
happened to prevent somebody buying them all up to hoard them, creating
artificial scarcity, and then charging a market sensitive price for
them, rather than the flat rate they cost now. That's not really any
different to an ISP paying RIR fees, and then indirectly passing those
costs onto their customers.


> This will compel ISP's to at least consider the issues, and it will most
> likely force users to buy into technologies that allow them to do what they
> want.  And inside a /64, you have sufficient space that there's probably
> nothing you can't do.  :-)
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail 
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many apples.


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mark Andrews]

>I think we got here when "site-local" went away - we've effectively
>redefined link-local to mean "site-local," while using globally unique
>addressing.

site-local was replaced with ULA.  Have you got your ULA yet? :-)

ULA gives you /48's.
6to4 gives you /48's.

Your customers already have /48's whether they know it or not
(and some do).

Mark

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> If operational simplicity of fixed length node addressing is a
> technical reason, then I think it is a compelling one. If you've ever
> done any reasonable amount of work with Novell's IPX (or other fixed
> length node addressing layer 3 protocols (mainly all of them except
> IPv4!)) you'll know what I mean.
> 
> I think Ethernet is also another example of the benefits of
> spending/"wasting" address space on operational convenience - who needs
> 46/47 bits for unicast addressing on a single layer 2 network!? If I
> recall correctly from bits and pieces I've read about early Ethernet,
> the very first versions of Ethernet only had 16 bit node addressing.
> They then decided to spend/"waste" bits on addressing to get
> operational convenience - "plug and play" layer 2 networking.

The difference is that it doesn't "cost" anything.  There are no RIR fees,
there is no justification.  You don't pay for, or have to justify, your 
Ethernet MAC addresses.

With IPv6, there are certain pressures being placed on ISP's not to be
completely wasteful.

This will compel ISP's to at least consider the issues, and it will most
likely force users to buy into technologies that allow them to do what they
want.  And inside a /64, you have sufficient space that there's probably
nothing you can't do.  :-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> Once upon a time, Florian Weimer <[EMAIL PROTECTED]> said:
> > >> Right now, we might say "wow, 256 subnets for a single end-user... 
> > >> hogwash!" and in years to come, "wow, only 256 subnets... what were we 
> > >> thinking!?"
> > >
> > > Well, what's the likelihood of the "only 256 subnets" problem?
> > 
> > There's a tendency to move away from (simulated) shared media networks.
> > "One host per subnet" might become the norm.
> 
> So each host will end up with a /64?

That's a risk.  It is more like "each host might end up with a /64."

Now, the thing here is, there's nothing wrong with one host per subnet.
There's just something wrong with blowing a /64 per subnet in an
environment where you have one host per subnet, and a limited amount of
bits above /64 (you essentially have /unlimited/ addresses within the 
/64, but an ISP may be paying for space, etc).

Now, understand, I /like/ the idea of /64 networks in general, but I do
have concerns about where the principle breaks down.  If we're agreed to
contemplate IPv6 as being a 64-bit address space, and then allocating 
space on that basis, I would suggest that some significant similarities 
to IPv4 appear.  In particular, a NAT gateway for IPv4 translates fairly
well into a subnet-on-a-/64 in IPv6.

That is interesting, but it may not actually reduce the confusion as to
how to proceed.

> How exactly are end-users expected to manage this?  Having a subnet for
> the kitchen appliances and a subnet for the home theater, both of which
> can talk to the subnet for the home computer(s), but not to each other,
> will be far beyond the abilities of the average home user.

Well, this gets back to what I was saying before.

At a certain point, Joe Sixpack might become sophisticated enough to have
an electrician come in and run an ethernet cable from the jack on the
fridge to his home router.  He might also be sophisticated enough to pay
$ElectronicsStore installation dep't to run an ethernet cable from the
jack on the home theater equipment to the home router.  I believe that
this may in fact have come to pass ...

Now the question is, "what should happen next."

The L3 option is that the home router presents a separate /64 on each
port, and offers some firewalling capabilities.  I hinted before that I
might not be thrilled with this, due to ISP commonly controlling CPE, but
that can be addressed by making the router separate.

There's a trivial L2 option as well.  You can simply devise a L2 switch
that implements filtering policies.  Despite all the cries of "that's
not how we do it in v4!" and "we can't change the paradigm," the reality
is that this /could/ be perfectly fine.  As a matter of fact, for Joe
Sixpack, it almost certainly /is/ fine.

Joe Sixpack's policy is going to read just like what you wrote above.
"subnet for appliances," "subnet for computer," "subnet for theater,"
with the appliances and theater only being able to talk to computer.
He's not going to care if it's an actual subnet or just a logical blob.
This is easy to do at L2 or L3.  We're more /used/ to doing it at L3,
but it's certainly workable at L2, and the interface to do so doesn't
necessarily even need to look any different, because Joe Sixpack does
not care about the underlying network topology and strategy.

I would absolutely like to see DHCP PD be usable for environments where
multiple prefixes are available and allowed, but I believe we're going
to also be needing to look at bridging.

There's /going/ to be some crummy ISP somewhere that only allocates end
users a /64, or there's /going/ to be a business with a network that will
refuse DHCP PD, and as a result there /will/ be a market for devices that
have the ability to cope.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sun, 23 Dec 2007 19:46:26 +0100
Florian Weimer <[EMAIL PROTECTED]> wrote:

> 
> * Joe Greco:
> 
> >> Right now, we might say "wow, 256 subnets for a single end-user... 
> >> hogwash!" and in years to come, "wow, only 256 subnets... what were we 
> >> thinking!?"
> >
> > Well, what's the likelihood of the "only 256 subnets" problem?
> 
> There's a tendency to move away from (simulated) shared media networks.
> "One host per subnet" might become the norm.

Or possibly maybe Peter M. Gleitz's and Steven M. Bellovin's idea of

"Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 
and Multiple Addresses per Host"

http://www.cs.columbia.edu/~smb/papers/tarp/tarp.html

A /64 per host is probably not necessary, however if an end-site has
a /48, that's 65K hosts so it wouldn't likely be much of a problem for
most sites ... certainly not my house currently or in the forseeable
future or my current employer, or most employers I've worked for in the
past.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sun, 23 Dec 2007 12:54:34 -0500
Ross Vandegrift <[EMAIL PROTECTED]> wrote:

> 
> On Sun, Dec 23, 2007 at 12:24:32AM +0100, Iljitsch van Beijnum wrote:
> > First of all, there's RFC 3513:
> > 
> > For all unicast addresses, except those that start with binary value  
> > 000, Interface IDs are required to be 64 bits long and to be  
> > constructed in Modified EUI-64 format.
> 
> Ahhh, thanks - that is the only thing I have ever seen that gives any
> reason for the /64 prefix.  Sadly, the document contains no
> compelling technical reasons for it - looks like it's done just so
> things are easy when generating interface IDs from ethernet addresses.
> 

If operational simplicity of fixed length node addressing is a
technical reason, then I think it is a compelling one. If you've ever
done any reasonable amount of work with Novell's IPX (or other fixed
length node addressing layer 3 protocols (mainly all of them except
IPv4!)) you'll know what I mean.

I think Ethernet is also another example of the benefits of
spending/"wasting" address space on operational convenience - who needs
46/47 bits for unicast addressing on a single layer 2 network!? If I
recall correctly from bits and pieces I've read about early Ethernet,
the very first versions of Ethernet only had 16 bit node addressing.
They then decided to spend/"waste" bits on addressing to get
operational convenience - "plug and play" layer 2 networking.

If IPv6 can have the same operational simplicity as Ethernet,
and addressing bits can afford to be spent on it, then I think those
bits are well worth spending.

The /64 for all subnets idea is probably an example of "worse is
better" principle. It's not ideal for everything, but because it's
general enough, it works with everything, and is simpler and a
*single* solution to everything, and that's what makes it better.

Regarding where the /64 boundary came from, from what I understand, the
following Internet Drafts are it's origin:

"8+8 - An Alternate Addressing Architecture for IPv6"
http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt

"GSE - An Alternate Addressing Architecture for IPv6"
http://arneill-py.sacramento.ca.us/ipv6mh/draft-ipng-gseaddr-00.txt

> > Second, we currently have two mechanisms to configure IPv6 hosts with  
> > an address: router advertisements and DHCPv6. The former has been  
> > implemented in ALL IPv6 stacks but doesn't work if your subnet isn't  
> > a /64.
> 
> But the protocols don't imply or require this.  All of the messages
> used in stateless autoconfig will behave as expected with longer prefix
> lengths.  So it seems that because the interface identifier has to be
> 64-bits, stateless autoconfig is unnecessarily crippled.
> 
> For kicks I just tried RAs with a /96 prefix.  Linux 2.6 checks and
> enforces the requirement from RFC3513, though it'd be trivial to
> change.  But I'm guessing other vendors enforce this as well.
> 
> -- 
> Ross Vandegrift
> [EMAIL PROTECTED]
> 
> "The good Christian should beware of mathematicians, and all those who
> make empty prophecies. The danger already exists that the mathematicians
> have made a covenant with the devil to darken the spirit and to confine
> man in the bonds of Hell."
>   --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37


-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Joe Greco]

> There is a huge detent at /48, but there's a certain amount of guidance
> that can only be derived from operational experience. It's not clear to
> me why /56 would be unacceptable, particularly if you're delegating them
> to a device that already has a /64. Are one's customers attached via
> point-to-point links, or do they sit on shared broadcast domain where
> their cpe is receiving a /128 and requesting pd from the outset?
> 
> When someone plugs an apple airport into a segment of the corporate lan
> should it be be able to request pd under those circumstances as well?
> how is that case different than plugging it in on a residential connection?
> 
> These are issues providers can and should grapple with. 

More likely, at least some of them are fairly naive questions.

For example, /experience/ tells us that corporate LAN policies are often
implemented without regard to what "we", as Internet engineers, would
prefer, so I can guarantee you with a 100% certainty that there will be
at least some networks, and more than likely many networks, where you
will not be able to simply request a prefix delegation and have that work
the way you'd like.  There will always be some ISP who has delegated, or
some end site who has received, a "far too close to being just large
enough" allocation, and so even if we assume that every router vendor
and IPv6 implementation from here to eternity has no knobs to disable
prefix delegation, simple prefix exhaustion within an allocation will be 
a problem.  All the screams of "but they should have been allocated more"
will do nothing to change this.

Further, if we consider, for a moment, a world where prefix delegation is
the only method of adding something like an Apple Airport to an existing
network, this is potentially encouraging the burning of /64's for the
addition of a network with perhaps a single client.  That's perfectly fine,
/as long as/ networks are allocated sufficient resources.  This merely
means that from a fairly pessimistic viewpoint, IPv6 is actually a 64-bit
address space for purposes of determining how much address space is
required.

So, from the point of view of someone manufacturing devices to attach to
IPv6 networks, I have some options.

I can:

1) Assume that DHCP PD is going to work, and that the end user will have
   a prefix to delegate, which might be valid or it might not.  This leaves
   me in the position of having to figure out a backup strategy, because I
   do not want users returning my device to Best Buy because "it don't
   work."  The backup strategy is bridging.

2) Assume that DHCP PD is not going to work, and make bridging the default
   strategy.  DHCP PD can optionally be a configurable thing, or autodetect,
   or whatever, but it will not be mandatory.

I am being facetious here, of course, since only one of those is really
viable in the market.  Anyone who thinks otherwise is welcome to explain to
me what's going to happen in the case where there are no P's to D.

I will leave the difference between corporate and residential as an exercise
to the reader; suffice it to say that the answers are rather obvious in the
same manner.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: v6 subnet size for DSL & leased line customers

[David Barak]

-- On Sun, 12/23/07, Chris Adams <[EMAIL PROTECTED]> wrote:

> From: Chris Adams <[EMAIL PROTECTED]>
> Subject: Re: v6 subnet size for DSL & leased line customers
> To: nanog@merit.edu
> Date: Sunday, December 23, 2007, 2:21 PM
> Once upon a time, Florian Weimer <[EMAIL PROTECTED]>
> said:
> > >> Right now, we might say "wow, 256
> subnets for a single end-user... 
> > >> hogwash!" and in years to come,
> "wow, only 256 subnets... what were we 
> > >> thinking!?"
> > >
> > > Well, what's the likelihood of the "only
> 256 subnets" problem?
> > 
> > There's a tendency to move away from (simulated)
> shared media networks.
> > "One host per subnet" might become the norm.
> 
> So each host will end up with a /64?
> 
> How exactly are end-users expected to manage this?  Having
> a subnet for
> the kitchen appliances and a subnet for the home theater,
> both of which
> can talk to the subnet for the home computer(s), but not to
> each other,
> will be far beyond the abilities of the average home user.


As I see it, one of the big benefits IPv4 provided was logical addresssing in 
an easy-to-understand and easy-to-aggregate manner, with small layer-2 networks 
divided by routers.  What we've gone to with IPv6 is a gigantic layer-2 network 
(the flat autoconfiguration space).  

I think we got here when "site-local" went away - we've effectively redefined 
link-local to mean "site-local," while using globally unique addressing.

Personally, I don't relish the idea of millions of hosts participating in 
spanning-tree, so I'd rather see us move back toward the direction of using 
layer-3 addresses to break up layer-2 islands.

How about this for a modest proposal for a capability:
Allow autoconfigured generation of IPv6 interface addresses to use this format:

(one byte VLAN ID) (48 bit MAC address)

instead of:

(24 bit half-mac) (FFFE) (24 bit half-MAC)

This would allow a CPE router to serve as the gateway for up to 64K VLANs, and 
wouldn't waste a byte in the middle of the address space.

How about it?

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: v6 subnet size for DSL & leased line customers

[Chris Adams]

Once upon a time, Florian Weimer <[EMAIL PROTECTED]> said:
> >> Right now, we might say "wow, 256 subnets for a single end-user... 
> >> hogwash!" and in years to come, "wow, only 256 subnets... what were we 
> >> thinking!?"
> >
> > Well, what's the likelihood of the "only 256 subnets" problem?
> 
> There's a tendency to move away from (simulated) shared media networks.
> "One host per subnet" might become the norm.

So each host will end up with a /64?

How exactly are end-users expected to manage this?  Having a subnet for
the kitchen appliances and a subnet for the home theater, both of which
can talk to the subnet for the home computer(s), but not to each other,
will be far beyond the abilities of the average home user.

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

Re: v6 subnet size for DSL & leased line customers

[Daniel Hagerty]

Ross Vandegrift <[EMAIL PROTECTED]> writes:

> Ahhh, thanks - that is the only thing I have ever seen that gives any
> reason for the /64 prefix.  Sadly, the document contains no
> compelling technical reasons for it - looks like it's done just so
> things are easy when generating interface IDs from ethernet addresses.

One good guess for the rationale is to preserve the possibility of
splitting the host and network identifier namespaces, like XNS and
some others do.  Should it be deemed the way forward, the current
policy makes it slightly more of a possibility to decouple them after
the fact.

Re: v6 subnet size for DSL & leased line customers

[Florian Weimer]

* Joe Greco:

>> Right now, we might say "wow, 256 subnets for a single end-user... 
>> hogwash!" and in years to come, "wow, only 256 subnets... what were we 
>> thinking!?"
>
> Well, what's the likelihood of the "only 256 subnets" problem?

There's a tendency to move away from (simulated) shared media networks.
"One host per subnet" might become the norm.

Re: v6 subnet size for DSL & leased line customers

[Ross Vandegrift]

On Sun, Dec 23, 2007 at 12:24:32AM +0100, Iljitsch van Beijnum wrote:
> First of all, there's RFC 3513:
> 
> For all unicast addresses, except those that start with binary value  
> 000, Interface IDs are required to be 64 bits long and to be  
> constructed in Modified EUI-64 format.

Ahhh, thanks - that is the only thing I have ever seen that gives any
reason for the /64 prefix.  Sadly, the document contains no
compelling technical reasons for it - looks like it's done just so
things are easy when generating interface IDs from ethernet addresses.

> Second, we currently have two mechanisms to configure IPv6 hosts with  
> an address: router advertisements and DHCPv6. The former has been  
> implemented in ALL IPv6 stacks but doesn't work if your subnet isn't  
> a /64.

But the protocols don't imply or require this.  All of the messages
used in stateless autoconfig will behave as expected with longer prefix
lengths.  So it seems that because the interface identifier has to be
64-bits, stateless autoconfig is unnecessarily crippled.

For kicks I just tried RAs with a /96 prefix.  Linux 2.6 checks and
enforces the requirement from RFC3513, though it'd be trivial to
change.  But I'm guessing other vendors enforce this as well.

-- 
Ross Vandegrift
[EMAIL PROTECTED]

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

Re: v6 subnet size for DSL & leased line customers

[Randy Bush]

Mohacsi Janos wrote:
> There plenty of organisation who has a dedicated team/person for
> network management (routers, switches etc.), while another
> team/person for system management (dhcp, servers etc.). So 
> configuring DHCPv6 requires cooperation which takes time, but users
> are complaining



so, what problems are there with dhcpv6 that differ from those we have
experienced with dchpv4?  what would be good to know before trying to
deploy it?

do organizations you know prefer autoconf or dhcpv6?  and why?

randy

Re: v6 subnet size for DSL & leased line customers

[Mohacsi Janos]

On Sun, 23 Dec 2007, Iljitsch van Beijnum wrote:



On 22 dec 2007, at 21:23, Ross Vandegrift wrote:


IPv6 documents seem to assume
that because auto-discovery on a LAN uses a /64, you always have to
use a /64 global-scope subnet.  I don't see any technical issues that
require this though.  ICMPv6 is capable of passing info on prefixes of
any length -  prefix length is a plain old 8bit field.



In fact, until I read the ARIN documents to receive an assignment at
work, I assumed this would be how people would operate.  So what's the
concern?  Give all end users a /64 and let them subnet that as they
see fit.  If DHCPv6 would take care of it automatically with shorter
prefixes, that's fine


First of all, there's RFC 3513:

For all unicast addresses, except those that start with binary value 000, 
Interface IDs are required to be 64 bits long and to be constructed in 
Modified EUI-64 format.


Second, we currently have two mechanisms to configure IPv6 hosts with an 
address: router advertisements and DHCPv6. The former has been implemented in 
ALL IPv6 stacks but doesn't work if your subnet isn't a /64. The latter is (I 
think) available on the client side in Windows Vista. There are a few DHCPv6 
server implementations, but the ones I tested 2 years ago wouldn't do address 
assignment. (You still need the router advertisements to learn your default 
gateway and prefix length as DHCPv6 can't tell you those.) So although many 
people want to stick to the DHCP model they know from IPv4, that's extremely 
hard to do with IPv6 the way things currently are.



Actually we tested DHCv6 implementation 2-3 years ago.
http://www.6net.org/publications/deliverables/D3.2.3v3.pdf

The dibbler seemed to be rather complete DHCPv6 implementation. I think 
default gateway and prefix length distribution via DHCPv6 will be quite 
problematical any many situation. There plenty of organisation who has a 
dedicated team/person for network management (routers, switches etc.), 
while another team/person for system management (dhcp, servers etc.). So 
configuring DHCPv6 requires cooperation which takes time, but users are 
complaining


Best Regards,
Janos Mohacsi

Re: v6 subnet size for DSL & leased line customers

[Mark Smith]

On Sat, 22 Dec 2007 12:53:52 -0800
"Christopher Morrow" <[EMAIL PROTECTED]> wrote:

> 
> On Dec 22, 2007 12:23 PM, Ross Vandegrift <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Dec 21, 2007 at 01:33:15PM -0500, Deepak Jain wrote:
> > > For example... Within one's own network (or subnet if you will) we can
> > > absorb all the concepts of V4 today and have lots of space available.
> > > For example... for the DMZ of a business... Why not give them 6 bits
> > > (/122?) are we anticipating topology differences UPSTREAM from the
> > > customers that can take advantage of subnet differences between /64 and
> > > /56 ?
> >
> > I am confused on this point as well.  IPv6 documents seem to assume
> > that because auto-discovery on a LAN uses a /64, you always have to
> > use a /64 global-scope subnet.  I don't see any technical issues that
> > require this though.  ICMPv6 is capable of passing info on prefixes of
> > any length -  prefix length is a plain old 8bit field.
> >
> 
> Uhm, so sure the spec might be able to do something different than /64
> but most equipment I've used only does auto-conf if the prefix is a
> /64 :( Somewhere along the path to ipng we got reverted to classful
> addressing again :(
> 

Not really. Classful IPv4 defined both an addressing structure *and* an
agorithm to match destinations against the route table entries (i.e.
classful forwarding won't match on a default route if the router knows
at least one prefix within a classful network).

IPv6 uses the longest match rule regardless of any addressing
structure, and only uses structure for a few portions of the total
IPv6 address space, for the operation of things like DHCPv6 and address
autoconfiguration. A change in IPv6 addressing structure won't involve
a change in the route table matching algorithm.

Regards,
Mark.

-- 

"Sheep are slow and tasty, and therefore must remain constantly
 alert."
   - Bruce Schneier, "Beyond Fear"

Re: v6 subnet size for DSL & leased line customers

[Mikael Abrahamsson]

On Sat, 22 Dec 2007, Joel Jaeggli wrote:


Leave enough address space for pd to occur? We know that if I hand you
the end-user a /64 that the first device that you connect to the network


What about the "wan" side of that connection? I want the customer to only 
source traffic from the /56 being assigned and I don't want ISP router to 
have any IPs in that space. Does IPv6 capable CPEs have the possibility to 
source packets from local network (received via pd) and only have FE80: IP 
for upstream routing which is never used as an SRC address for 
communication with the outside world (apart from upstream router)?


If not, is this something that we should ask the CPE vendors for? It would 
be extremely nice for CoPP etc for ISP routers to have no IP in customer 
space, and CPEs to have no IP in ISP link-network space. Would make for 
very effective infrastructure ACLs.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]