Re: IPv6 - real vs theoretical problems

[Joel Jaeggli]

On 1/11/11 11:15 AM, Jack Bates wrote:
> 
> 
> On 1/11/2011 1:05 PM, George Bonser wrote:
>> Many of us are looking at things from today's
>> perspective.  Maybe each room of my house will have its own subnet with
>> a low power access point and I can find which room something is in by
>> the IP address it has.
> 
> Today, there are several vendors who believe the wireless part of their
> cpe should be a different subnet than the ethernet. There are multiple
> cases of stacked routers in homes, which requires multiple DHCPv6-PD
> delegations, and the current philosophy is very wasteful (as DHCPv6
> itself doesn't support variable sized requests, chained requesting, and
> other options which would make it efficient for a requesting router 3
> routers away from the initial DHCPv6 server).

There are also devices (even consumer ones) that support seperate ssids
for guests and other users with different security policy for each as
well as layer-3 seperation. in my direct experience with the d-link it
doesn't (yet) route v6 to the guest network.

> 
> Jack
> 

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 12, 2011, at 9:34 AM, Ted Fischer wrote:

> At 11:59 AM 1/12/2011, Jim postulated wrote:
> 
>> On 01/11/2011 01:31 PM, Owen DeLong wrote:
>> > It's not about the number of devices. That's IPv4-think. It's about the 
>> > number
>> > of segments. I see a world where each home-entertainment cluster would
>> > be a separate segment (today, few things use IP, but, future HE solutions
>> > will include Monitors, Amps, Blu-Ray players, and other Media gateways
>> > that ALL have ethernet ports for control and software update).
>> 
>> Your future is now, Owen.  I have four network devices at my primary
>> television -- the TV itself, TiVo, PS3, and Wii (using the wired
>> adapter).  All told, I have seven networked home entertainment devices
>> in my house, with another (Blu-Ray player) likely coming soon.  I feel
>> confident in saying that my use case isn't unusual these days.
>> 
>> While a lot of the scalability concerns are blown off as "not applying
>> to typical consumers," we're quickly getting to the point where your
>> average joe IS somewhat likely to have different classes of devices that
>> might benefit from being on separate subnets.
>> 
>> Jima
> 
> I helped a friend setup his "home network" recently.  He is using an old 
> Linksys Router with no v6 support.  I like to be conservative and only 
> allocate what might be needed ... part of my "Defense in Depth" strategy to 
> provide some layer of "security" with NAT (yes, I know - my security by 
> obscurity is to use something from 172.16) and a limited amount of addresses 
> to allocate (not to mention WPA2 - he had default no security when I first 
> got there).  Used to be a /29 would be sufficient for any home.  But, before 
> I knew it, he had a wireless printer, laptop, and 4 iPhones all needing the 
> new wireless passphrase to connect, plus he was anticipating 2 more laptops 
> (one each for his children - to whom 2 of the iPhones belonged), and 
> addresses set aside for guests and the occasional business visitor (he works 
> from home).  I left him configured with a /28, and told him to call me if he 
> anticipated more.
> 
> As a side security note - we lost the laptop on the "new" secured network 
> before I tracked down that it had automatically logged in to his neighbor's 
> (also unprotected) network on reboot.
> 
> Ted
> 

I'm not sure how you see limiting available addresses as a security feature 
rather than just a nuisance, but, to each their own.


Owen

Re: IPv6 - real vs theoretical problems

[Ted Fischer]

At 11:59 AM 1/12/2011, Jim postulated wrote:


On 01/11/2011 01:31 PM, Owen DeLong wrote:
> It's not about the number of devices. That's IPv4-think. It's 
about the number

> of segments. I see a world where each home-entertainment cluster would
> be a separate segment (today, few things use IP, but, future HE solutions
> will include Monitors, Amps, Blu-Ray players, and other Media gateways
> that ALL have ethernet ports for control and software update).

 Your future is now, Owen.  I have four network devices at my primary
television -- the TV itself, TiVo, PS3, and Wii (using the wired
adapter).  All told, I have seven networked home entertainment devices
in my house, with another (Blu-Ray player) likely coming soon.  I feel
confident in saying that my use case isn't unusual these days.

 While a lot of the scalability concerns are blown off as "not applying
to typical consumers," we're quickly getting to the point where your
average joe IS somewhat likely to have different classes of devices that
might benefit from being on separate subnets.

 Jima


I helped a friend setup his "home network" recently.  He is using an 
old Linksys Router with no v6 support.  I like to be conservative and 
only allocate what might be needed ... part of my "Defense in Depth" 
strategy to provide some layer of "security" with NAT (yes, I know - 
my security by obscurity is to use something from 172.16) and a 
limited amount of addresses to allocate (not to mention WPA2 - he had 
default no security when I first got there).  Used to be a /29 would 
be sufficient for any home.  But, before I knew it, he had a wireless 
printer, laptop, and 4 iPhones all needing the new wireless 
passphrase to connect, plus he was anticipating 2 more laptops (one 
each for his children - to whom 2 of the iPhones belonged), and 
addresses set aside for guests and the occasional business visitor 
(he works from home).  I left him configured with a /28, and told him 
to call me if he anticipated more.


As a side security note - we lost the laptop on the "new" secured 
network before I tracked down that it had automatically logged in to 
his neighbor's (also unprotected) network on reboot.


Ted

Re: IPv6 - real vs theoretical problems

[Jima]

On 01/11/2011 01:31 PM, Owen DeLong wrote:
> It's not about the number of devices. That's IPv4-think. It's about the number
> of segments. I see a world where each home-entertainment cluster would
> be a separate segment (today, few things use IP, but, future HE solutions
> will include Monitors, Amps, Blu-Ray players, and other Media gateways
> that ALL have ethernet ports for control and software update).

 Your future is now, Owen.  I have four network devices at my primary
television -- the TV itself, TiVo, PS3, and Wii (using the wired
adapter).  All told, I have seven networked home entertainment devices
in my house, with another (Blu-Ray player) likely coming soon.  I feel
confident in saying that my use case isn't unusual these days.

 While a lot of the scalability concerns are blown off as "not applying
to typical consumers," we're quickly getting to the point where your
average joe IS somewhat likely to have different classes of devices that
might benefit from being on separate subnets.

 Jima

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 11, 2011, at 10:45 AM, Michael Loftis wrote:

> On Fri, Jan 7, 2011 at 3:44 PM, Owen DeLong  wrote:
> 
>> There are multiple purposes to /48s to residential end users.
>> 
>> DHCP-PD allows a lot of future innovations not yet available.
>> 
>>Imagine a house where the border router receives a /48
>>from the ISP and delegates /64s or /60s or whatever to
>>other routers within the house.
>> 
>>Each home entertainment cluster may be one group of
>>networks with its own router.
>> 
>>The appliance network(s) may have their own router(s).
>> 
>>RFID tags on groceries may lead to a time when your
>>home automation server can gather up data from your
>>refrigerator, pantries, etc. and present the inventory
>>on your mobile phone while you're at the grocery store.
>>No more need to maintain a shopping list, just query
>>the inventory from the store.
>> 
>> These are just the things that could easily be done with the
>> technology we already know about. Imagine what we might
>> think of once we get more used to having prefix abundance.
> 
> 
> Having more address space won't help most of these uses, and as for
> why, take a look at the proposed situation with for example home media

Yes, it will...

> serving/sharing systems by TiVo, Apple, etc. They all require that the
> units be within the same broadcast domain or that there be a
> configured bridge of some sort if they even allow that topology.  They

That is the current state of the art which is the direct result of the lack
of address space and the lack of the features I am describing making
this absolutely necessarily.

> (actually rightfully) assume that the network topology is flat, single
> broadcast domain, and mroe and more use Multicast DNS (which I've seen

Yes, that assumption is valid today. Future technology can change that
assumption in useful and meaningful ways.

> called a bunch of different things)  More to the point, your average
> home user can not technically fathom anything more complicated than
> "plug it in" -- and many begin to fail to set something up properly
> when its extended to something as complicated as "plug it in, push a
> button" or "plug it in, type some numbers into the device"

DHCP-PD will allow for hierarchical topology that is not more complicated
than "plug it in". No button push, no typing something in. Literally plug
it in.
> 
> Your average home user has no reason at all for anything more than a
> PtP to his/her gateway, and a single prefix routed to that gateway.

Correct. I'm just saying that prefix should be a /48 so that the gateway
can work with the other gateways inside the house to designate the
best topology within the house. Note, this is all automated. It doesn't
require the end-user to actually do anything other than plug it in.

> There are most certainly a few (which includes I'm sure 99% of the
> NANOGers!) subscribers who can and will use more space than that, and
> ISPs most definitely should make /48s readily and easily available for
> those customers, but giving each and every customer a /48 (or really,
> even a pair of /64s, one for the PtP, one delegated) is almost
> certainly overkill.  The devices won't use the extra space unless

That is today only thinking. Toss out your IPv4 scarcity-based assumptions
about what is possible. IPv6 does have new features and new capabilities
that we are just beginning to consider.

> there's some automagic way of them communicating the desire to
> eachother, and appropriately configuring themselves, and it would have
> to be very widely accepted.  But there's no technical gain.  A typical

It's called DHCPv6-PD and it already exists. That's the point!!

> household would probably have less than about 50, maybe 100 devices,
> even if we start networking appliances like toasters, hair dryers and
> every single radio, tv, and light switch.
> 
It's not about the number of devices. That's IPv4-think. It's about the number
of segments. I see a world where each home-entertainment cluster would
be a separate segment (today, few things use IP, but, future HE solutions
will include Monitors, Amps, Blu-Ray players, and other Media gateways
that ALL have ethernet ports for control and software update). The
kitchen appliances would probably have their own segment. A refrigerator
or pantry may have a front-end router that separates the household
backbone from the network interfacing all the RFIDs contained within
the device. I'm sure there are other examples where automated
segmentation of the network can, does, and will make sense.

We're just starting to explore this. The point is to have address delegation
policies which don't interfere with this development.

> Just my 2 cents worth.

I'll see your $0.02 and raise you $0.48 ;-)

Owen

Re: IPv6 - real vs theoretical problems

[Jack Bates]

On 1/11/2011 1:05 PM, George Bonser wrote:

Many of us are looking at things from today's
perspective.  Maybe each room of my house will have its own subnet with
a low power access point and I can find which room something is in by
the IP address it has.


Today, there are several vendors who believe the wireless part of their 
cpe should be a different subnet than the ethernet. There are multiple 
cases of stacked routers in homes, which requires multiple DHCPv6-PD 
delegations, and the current philosophy is very wasteful (as DHCPv6 
itself doesn't support variable sized requests, chained requesting, and 
other options which would make it efficient for a requesting router 3 
routers away from the initial DHCPv6 server).



Jack

RE: IPv6 - real vs theoretical problems

[George Bonser]

> From: Michael Loftis 
> Sent: Tuesday, January 11, 2011 10:46 AM
> To: nanog
> Subject: Re: IPv6 - real vs theoretical problems


> Your average home user has no reason at all for anything more than a
> PtP to his/her gateway, and a single prefix routed to that gateway.
> There are most certainly a few (which includes I'm sure 99% of the
> NANOGers!) subscribers who can and will use more space than that, and
> ISPs most definitely should make /48s readily and easily available for
> those customers, but giving each and every customer a /48 (or really,
> even a pair of /64s, one for the PtP, one delegated) is almost
> certainly overkill.  The devices won't use the extra space unless
> there's some automagic way of them communicating the desire to
> eachother, and appropriately configuring themselves, and it would have
> to be very widely accepted.  But there's no technical gain.  A typical
> household would probably have less than about 50, maybe 100 devices,
> even if we start networking appliances like toasters, hair dryers and
> every single radio, tv, and light switch.
> 
> Just my 2 cents worth.

And what is to say that some devices won't have several different IPs?
Maybe a different subnet is associated with each individual in the
household when getting their voicemail or making DVR recordings or
whatever.And I might want the stuff in my garage on a different
subnet that the stuff in my living room because it has different access
policy. To say " Your average home user has no reason at all ..." seems
like saying the average user will have no reason at all to need more
than 640K of RAM.  Many of us are looking at things from today's
perspective.  Maybe each room of my house will have its own subnet with
a low power access point and I can find which room something is in by
the IP address it has.  I have no idea, but do believe there is no
reason to be restrictive in network assignments with v6.

Re: IPv6 - real vs theoretical problems

[Michael Loftis]

On Fri, Jan 7, 2011 at 3:44 PM, Owen DeLong  wrote:

> There are multiple purposes to /48s to residential end users.
>
> DHCP-PD allows a lot of future innovations not yet available.
>
>        Imagine a house where the border router receives a /48
>        from the ISP and delegates /64s or /60s or whatever to
>        other routers within the house.
>
>        Each home entertainment cluster may be one group of
>        networks with its own router.
>
>        The appliance network(s) may have their own router(s).
>
>        RFID tags on groceries may lead to a time when your
>        home automation server can gather up data from your
>        refrigerator, pantries, etc. and present the inventory
>        on your mobile phone while you're at the grocery store.
>        No more need to maintain a shopping list, just query
>        the inventory from the store.
>
> These are just the things that could easily be done with the
> technology we already know about. Imagine what we might
> think of once we get more used to having prefix abundance.


Having more address space won't help most of these uses, and as for
why, take a look at the proposed situation with for example home media
serving/sharing systems by TiVo, Apple, etc. They all require that the
units be within the same broadcast domain or that there be a
configured bridge of some sort if they even allow that topology.  They
(actually rightfully) assume that the network topology is flat, single
broadcast domain, and mroe and more use Multicast DNS (which I've seen
called a bunch of different things)  More to the point, your average
home user can not technically fathom anything more complicated than
"plug it in" -- and many begin to fail to set something up properly
when its extended to something as complicated as "plug it in, push a
button" or "plug it in, type some numbers into the device"

Your average home user has no reason at all for anything more than a
PtP to his/her gateway, and a single prefix routed to that gateway.
There are most certainly a few (which includes I'm sure 99% of the
NANOGers!) subscribers who can and will use more space than that, and
ISPs most definitely should make /48s readily and easily available for
those customers, but giving each and every customer a /48 (or really,
even a pair of /64s, one for the PtP, one delegated) is almost
certainly overkill.  The devices won't use the extra space unless
there's some automagic way of them communicating the desire to
eachother, and appropriately configuring themselves, and it would have
to be very widely accepted.  But there's no technical gain.  A typical
household would probably have less than about 50, maybe 100 devices,
even if we start networking appliances like toasters, hair dryers and
every single radio, tv, and light switch.

Just my 2 cents worth.

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

> 
>> 
>> My frame of reference is that while we need to make the addresses big
>> enough, we also need to preserve the hierarchy.  There is no shortage
>> of addresses, nor will there be, ever, but there could be a shortage
>> of levels in the hierarchy. I assume you would like a home to have a
>> /48?  But, from my provider's /32, that is only 4 levels at the
>> assumed nibble boundary.  I think my provider could use another
>> two levels.
> 
> If your provide has more than 10,000 customers they should never have gotten 
> a /32. The braindead notion that everyone needed to rush out and get a /32 
> has not helped get IPv6 deployed. The /32 value was the default one for a 
> startup provider. Every provider with a customer base should have done a plan 
> for a /48 per customer, then gotten the right size block to start with. Any 
> provider with a /32 and more than 10k customers needs to do that now and swap 
> for 'a real block', instead of trying to squeeze their customers into a tiny 
> block due to their insufficient initial request. 
> 
ARIN proposal 121 is seeking to clarify this in the NRPM. I've
also submitted a similar proposal to APNIC and expect it to be
published shortly and discussed in Hong Kong.

Unfortunately, I won't be in Hong Kong for the discussion, but, I'm going
to try and participate remotely.

I encourage anyone facing the /32 is not enough problem at the
service provider (or anyone else for that matter) to get involved
and speak up in favor of proposal 121 and/or the APNIC
equivalent.

I intend to put forth similar proposals where necessary in the other RIRs
as well.

Owen

RE: IPv6 - real vs theoretical problems

[Tony Hain]

*requested anonymous* wrote:
> (I don't post on public mailing lists, so, please consider this
> private.
> That is, I don't care if the question/reply are public, just, not the
> source.)
> 
> On 1/10/11 11:46 AM, Tony Hain wrote:
> > ... yes I know you understand operational issues.
> >
> > While managed networks can 'reverse the damage', there is no way to
> fix that
> > for consumer unmanaged networks. Whatever gets deployed now, that is
> what
> > the routers will be built to deal with, and it will be virtually
> impossible
> > to change it due to the 'installed base' and lack of knowledgeable
> > management.
> >
> > It is hard enough getting the product teams to accept that it is
> possible to
> > build a self-configuring home network without having that be crippled
> by
> > braindead conservation. The worst possible value I can see for
> delegation to
> > the home is /56, yet that is the most popular value because people
> have
>   ^
> Why would you say /56 is the worst possible value?  Just curious --

I am actually trying to develop a simple set of 'auto conf' rules for all the 
CPE vendors to build against, and for a Joe-sixpack plug-n-play network 
configuration a /56 means there is only one topology option beyond single 
subnet. 

> my provider doesn't offer IPv6 yet, but, I think they will soon.
> I was going to ask for a /56 for my home net.  If I ever get around
> to using them to set up a domain for my wife's business, I will ask
> for a /48, but, for a house without a private domain, /56 seems
> perfect.

You are thinking of a managed network. Connect a random graph of boxes, then 
figure out a subnet scheme that all cpe vendors can implement that will 
correctly deal with prefix delegation and hierarchical routing. 


> I don't expect to run out in my lifetime, or even my children's
> or grandchildren's lifetimes if somehow the house stays in the family
> ;-)
> How many subnets will they really need, no matter if every lightbulb
> is on the net?

Wrong question. In a managed network that would be the right question, but in 
an unmanaged one the right question is how many sub-delegations and how many 
branches per sub-delegate are going to be automatically figured out. 

> 
> My frame of reference is that while we need to make the addresses big
> enough, we also need to preserve the hierarchy.  There is no shortage
> of addresses, nor will there be, ever, but there could be a shortage
> of levels in the hierarchy. I assume you would like a home to have a
> /48?  But, from my provider's /32, that is only 4 levels at the
> assumed nibble boundary.  I think my provider could use another
> two levels.

If your provide has more than 10,000 customers they should never have gotten a 
/32. The braindead notion that everyone needed to rush out and get a /32 has 
not helped get IPv6 deployed. The /32 value was the default one for a startup 
provider. Every provider with a customer base should have done a plan for a /48 
per customer, then gotten the right size block to start with. Any provider with 
a /32 and more than 10k customers needs to do that now and swap for 'a real 
block', instead of trying to squeeze their customers into a tiny block due to 
their insufficient initial request. 

> 
> I also think ~256 subnets has stood the test of time -- seldom in
> the last 25 years has a geographically contiguous enterprise network
> (such as a university or company) required more than 256 subnets --
> except for cisco, microsoft, et al., but not, e.g. most colleges,
> universities, research centers, etc.  More addresses, sure, but,
> not usually more than 256 subnets.  So, even in a world where
> every possible device has its own set of addresses -- how many
> subnets will I really need?

Again, wrong question. Most of the possible subnets in a Joe-sixpack 
configuration will be 'wasted'. So what? That space will be wasted sitting on 
the shelf at IANA in 500 years when someone comes up with a better idea. IPv6 
is not the last protocol known to mankind (unless the 2012 predictions are 
true), so most of its potential space will be wasted. Get over that point and 
accept that innovation requires thinking differently than the limited myopia of 
the past.

> 
> Also from my frame of reference -- we need to work on making addressing
> and re-addressing easier and more automatic for consumers anyway, so,
> if /56 is not enough, we can easily and painlessly switch to a /52
> with no problems.  

Easy in a managed network where it is possible to update code and expect that 
things will happen in a timeframe that makes development worth the effort. 
Impossible in consumer land where it is well documented that things are never 
updated, and all vendors need to play by the same simple rules because there is 
no hope that the consumer will know how to tweak them.

> And, if I decide to grow an enterprise from home,
> I feel that I should be able to re-address as needed over the course
> of time 

RE: IPv6 - real vs theoretical problems

[Tony Hain]

... yes I know you understand operational issues.

While managed networks can 'reverse the damage', there is no way to fix that
for consumer unmanaged networks. Whatever gets deployed now, that is what
the routers will be built to deal with, and it will be virtually impossible
to change it due to the 'installed base' and lack of knowledgeable
management. 

It is hard enough getting the product teams to accept that it is possible to
build a self-configuring home network without having that be crippled by
braindead conservation. The worst possible value I can see for delegation to
the home is /56, yet that is the most popular value because people have
their heads so far into the dark void of conservation they can't let accept
that the space will be 'wasted sitting on the shelf at IANA when somebody
comes along with a better idea in the next 500 years'. 

I understand the desire to 'do it like we do with IPv4', because that
reduces the learning curve, but it also artificially restricts IPv6, ensures
that the work is doubled to remove the restraints later, and makes it even
harder to show value in the short term because 'it is just like IPv4 with a
different bit pattern'. "IPv6 is not just IPv4 with bigger addresses" no
matter what the popular mantra is. The only way you can even get close to
that kind of argument is if you totally myopic on BGP, and even then there
are differences. 

Bottom line, just fix the tools to deal with the reality of IPv6, and move
on. 
Tony


> -Original Message-
> From: Deepak Jain [mailto:dee...@ai.net]
> Sent: Thursday, January 06, 2011 2:01 PM
> To: NANOG list
> Subject: IPv6 - real vs theoretical problems
> 
> 
> Please, before you flame out, recognize I know a bit of what I am
> talking about. You can verify this by doing a search on NANOG archives.
> My point is to actually engage in an operational discussion on this and
> not insult (or be insulted).
> 
> While I understand the theoretical advantages of /64s and /56s and /48s
> for all kinds of purposes, *TODAY* there are very few folks that are
> actually using any of them. No typical customer knows what do to do
> (for the most part) with their own /48, and other than
> autoconfiguration, there is no particular advantage to a /64 block for
> a single server -- yet. The left side of the prefix I think people and
> routers are reasonably comfortable with, it's the "host" side that
> presents the most challenge.
> 
> My interest is principally in servers and high availability equipment
> (routers, etc) and other things that live in POPs and datacenters, so
> autoconfiguration doesn't even remotely appeal to me for anything. In a
> datacenter, many of these concerns about having routers fall over exist
> (high bandwidth links, high power equipment trying to do as many things
> as it can, etc).
> 
> Wouldn't a number of problems go away if we just, for now, follow the
> IPv4 lessons/practices like allocating the number of addresses a
> customer needs --- say /122s or /120s that current router architectures
> know how to handle -- to these boxes/interfaces today, while just
> reserving /64 or /56 spaces for each of them for whenever the magic day
> comes along where they can be used safely?
> 
> As far as I can tell, this "crippling" of the address space is
> completely reversible, it's a reasonable step forward and the only
> "operational" loss is you can't do all the address jumping and
> obfuscation people like to talk about... which I'm not sure is a loss.
> 
> In your enterprise, behind your firewall, whatever, where you want
> autoconfig to work, and have some way of dealing with all of the dead
> space, more power to you. But operationally, is *anything* gained today
> by giving every host a /64 to screw around in that isn't accomplished
> by a /120 or so?
> 
> Thanks,
> 
> DJ
> 
> 

Re: IPv6 - real vs theoretical problems

[Dobbins, Roland]

On Jan 9, 2011, at 12:11 AM, Sam Stickland wrote:

> Why do you say there is zero state at the server, but the not at the client? 

Because every incoming connection to the server is unsolicited - therefore, 
there's no pre-existing state to evaluate.


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: IPv6 - real vs theoretical problems

[Sam Stickland]

On Sat, Jan 8, 2011 at 2:00 AM, Dobbins, Roland  wrote:
>
>
> If it's inappropriately placed in front of servers, where's there's no
> state to inspect and were the stateful nature of the device in and of itself
> forms a DoS vector, it has negative security value; i.e., it makes things
> far worse.


Roland, I'm missing something here. Why do you say there is zero state at
the server, but the not at the client? (Because of all the servers TCP/UDP
ports are well known perhaps?)

Sam

Re: IPv6 - real vs theoretical problems

[William Herrin]

On Fri, Jan 7, 2011 at 9:00 PM, Dobbins, Roland  wrote:
> On Jan 8, 2011, at 8:54 AM, William Herrin wrote:
>> I presume you don't intend us to conclude that a bastion
>> host firewall provides no security benefit to the equipment it
>> protects.
>
> If it's protecting workstations, yes, it has some positive security value - 
> but not due to NAT.

Hi Roland,

I see. Would I misstate your view if I characterized it as:

"A bastion host firewall which simulates identical IP addresses on
both sides provides at least as effective security as an otherwise
identical firewall which does not."

Regards,
Bill Herrin




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

Re: IPv6 - real vs theoretical problems

[Dobbins, Roland]

On Jan 8, 2011, at 8:54 AM, William Herrin wrote:

> I presume you don't intend us to conclude that a bastion host firewall 
> provides no security benefit to the equipment it
> protects.

If it's protecting workstations, yes, it has some positive security value - but 
not due to NAT.

If it's inappropriately placed in front of servers, where's there's no state to 
inspect and were the stateful nature of the device in and of itself forms a DoS 
vector, it has negative security value; i.e., it makes things far worse.


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: IPv6 - real vs theoretical problems

[William Herrin]

On Fri, Jan 7, 2011 at 8:02 PM, Dobbins, Roland  wrote:
> NAT has no inherent security benefits whatsoever.

Hi Roland,

With that statement, you paint with a remarkably broad brush. As you
know, folks use (or perhaps misuse) the term "NAT" to describe
everything from RFC 1631 to so-called "transparent proxies" which are
basically bastion hosts with some fancy behavior on the interior
interface. I presume you don't intend us to conclude that a bastion
host firewall provides no security benefit to the equipment it
protects. Would you care to clarify which of that range of
technologies you consider to serve no security function?

Regards,
Bill Herrin


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

Re: IPv6 - real vs theoretical problems

[Dobbins, Roland]

On Jan 8, 2011, at 5:44 AM, Owen DeLong wrote:

> You say dogma, I say mythology.

Concur 100%.

> Stateful inspection provides security.

To clarify, stateful inspection only provides security in a context where 
there's state to inspect - i.e., at the southernmost end of access networks, 
directly in front of machines which are serving as client workstations.  

In all other contexts, such as in front of servers and in the middle of access 
networks, stateful inspection has no security benefit whatsoever, and is 
actually quite harmful, with a hugely negative effect on security.

;>


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: IPv6 - real vs theoretical problems

[Dobbins, Roland]

On Jan 8, 2011, at 3:29 AM, Deepak Jain wrote:

>  There are now years of security dogma that says NAT is a good thing, 

Actually, this isn't the case.  There's some *security theater* dogma which 
makes totally unsupported claims about the supposed security benefits of NAT, 
but that's not quite the same thing.

;>

NAT has no inherent security benefits whatsoever, and quite a few security 
drawbacks.  


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 7, 2011, at 12:29 PM, Deepak Jain wrote:

>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html
>>> 
>>>Jima
>> 
> 
> Just skimming through the draft: 
> 
> 1) It is no longer recommended that /128s be given out. While there
>may be some cases where assigning only a single address may be
>justified, a site by definition implies multiple subnets and
>multiple devices.
> 
> --- I never knew a site, by definition, has multiple subnets and devices.
> 
>   A key principle for address management is that end sites always
>be able to obtain a reasonable amount of address space for their
>actual and planned usage, and over time ranges specified in
>years rather than just months. In practice, that means at least
>one /64, and in most cases significantly more. One particular
>situation that must be avoided is having an end site feel
>compelled to use IPv6-to-IPv6 Network Address Translation or
>other burdensome address conservation techniques because it
>could not get sufficient address space.
> 
> I think this is the real point everyone is trying to get at. They want IP6 to 
> be the end of NAT. Got it. There are now years of security dogma that says 
> NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma 
> went another way. This concept will take a long time to unwind. Somehow this 
> is supposed to mesh with dynamic renumbering where we can move around between 
> /48s without "too much burden" while wildly waving our hands at all the 
> higher-level configs (DNS, Applications, firewalls, etc) that don't play 
> nicely with automatic renumbering.
> 
You say dogma, I say mythology.

Stateful inspection provides security. NAT, by itself, does not. The reason 
people are confused about this
is because overloaded NAT cannot occur without stateful inspection.

Actually, DNS can be made to play relatively nicely with automatic renumbering 
and most client
hosts don't need DNS entries anyway.

Firewalls generally apply policy to network segments and not individual 
policies to migratory
hosts. Yes, it might be nice if they could, but, that's a hard problem to solve 
in a secure fashion.
Generally, nomadic or migratory hosts can usually accept the security policy 
for the network
to which they are attached and augment it with their own host-based 
firewall/filter rules
in any case. In such a case, the host-based rules can be written in terms of 
interfaces
and directions without much regard to the renumbering of the host in question.

> There is some convoluted discussion about how they wanted their /48 policy to 
> somehow encourage residential ISPs to give their users more IP space in the 
> base offering. I'm not sure why or what purpose an addressing policy should 
> have to a business case. I see nothing motivating a residential ISP 
> (especially one providing CPE equipment) to change their current deployment 
> system one iota. And I'm pretty sure they are the ones MOST exposed to abuses 
> of this address space by the least technical user base. (side note, if I were 
> a residential ISP I'd configure a /64 to my highly-controlled CPE router and 
> issue /128s to each and every device that plugged in on the customer site, 
> and only one per MAC and have a remotely configurable limit of say 50 devices 
> or whatever the mac table limit was. So I only have one route entry in my 
> aggregation layer and if the customer blows his CPE router up, I'm still 
> protected.)
> 
If you were an ISP, you wouldn't be one I would subscribe to.

There are multiple purposes to /48s to residential end users.

DHCP-PD allows a lot of future innovations not yet available.

Imagine a house where the border router receives a /48
from the ISP and delegates /64s or /60s or whatever to
other routers within the house.

Each home entertainment cluster may be one group of
networks with its own router.

The appliance network(s) may have their own router(s).

RFID tags on groceries may lead to a time when your
home automation server can gather up data from your
refrigerator, pantries, etc. and present the inventory
on your mobile phone while you're at the grocery store.
No more need to maintain a shopping list, just query
the inventory from the store.

These are just the things that could easily be done with the
technology we already know about. Imagine what we might
think of once we get more used to having prefix abundance.

> Question - Whatever happened to the concept of a customer coming to their SP 
> for more space? Why do we have to give them enough space for a decade of 
> theoretical use when every week we could widen their subnet without causing 
> any negative impact on them? No renumbering, etc. It's not considered a 
> burden today, but under IP6 it is? Heck, since space is so plentiful, we can 
> 

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 7, 2011, at 10:12 AM, Randy McAnally wrote:

> -- Original Message ---
> From: Jeff Wheeler 
> Sent: Thu, 6 Jan 2011 21:01:12 -0500
> 
>> Are there any large transit networks doing /64 on point-to-point
>> networks to BGP customers?  Who are they?
> 
> Add HE.net to the list.
> 
> -Randy
> www.fastserv.com

Correct... HE uses /64 on point-to-point links.

We give tunnel broker customers a /64 if they only want a single network and
a /48 upon request.

Owen

Re: IPv6 - real vs theoretical problems

[William Herrin]

On Fri, Jan 7, 2011 at 3:29 PM, Deepak Jain  wrote:
> Question - Whatever happened to the concept of a customer
> coming to their SP for more space? [E]very week we could
> widen their subnet without causing any negative
> impact on them?

Clever folks figured that making the customer wait for support hours
and then paying people to process configuration changes could be
usefully removed from the business cycle?

Regards,
Bill Herrin


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

RE: IPv6 - real vs theoretical problems

[Mikael Abrahamsson]

On Fri, 7 Jan 2011, Deepak Jain wrote:

least technical user base. (side note, if I were a residential ISP I'd 
configure a /64 to my highly-controlled CPE router and issue /128s to 
each and every device that plugged in on the customer site, and only one 
per MAC and have a remotely configurable limit of say 50 devices or 
whatever the mac table limit was. So I only have one route entry in my 
aggregation layer and if the customer blows his CPE router up, I'm still 
protected.)


This is exactly the reason to issue /48 or /56 to the end user. You give 
them plenty of space, and you then don't have to care anymore about what 
the user does with this space. You keep do LL only between CPE and PE, so 
you only need to keep 4 TCAM entries per customer (one for the /XX route, 
one for the LL adjacancy, one for the permit ACL to permit packets from 
the /XX, and one deny line. (I might be misunderstanding exactly what's 
needed here and a few TCAM entries more are needed, but you get the idea).


until routers get smarter, I don't see how all that dead routable space 
is a good thing.  Customers are paying for and getting a service, a 
continuous relationship with some set of SPs. In that service they


If I give them a /56 then it's zero administration for me for the 
forseeable future. Why on earth would I want to handle customer 
administration when I don't need to?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

RE: IPv6 - real vs theoretical problems

[Deepak Jain]

> > http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html
> >
> > Jima
> 

Just skimming through the draft: 

 1) It is no longer recommended that /128s be given out. While there
may be some cases where assigning only a single address may be
justified, a site by definition implies multiple subnets and
multiple devices.

--- I never knew a site, by definition, has multiple subnets and devices.

   A key principle for address management is that end sites always
be able to obtain a reasonable amount of address space for their
actual and planned usage, and over time ranges specified in
years rather than just months. In practice, that means at least
one /64, and in most cases significantly more. One particular
situation that must be avoided is having an end site feel
compelled to use IPv6-to-IPv6 Network Address Translation or
other burdensome address conservation techniques because it
could not get sufficient address space.

I think this is the real point everyone is trying to get at. They want IP6 to 
be the end of NAT. Got it. There are now years of security dogma that says NAT 
is a good thing, in the 20+ years IP6 has been on the books, the dogma went 
another way. This concept will take a long time to unwind. Somehow this is 
supposed to mesh with dynamic renumbering where we can move around between /48s 
without "too much burden" while wildly waving our hands at all the higher-level 
configs (DNS, Applications, firewalls, etc) that don't play nicely with 
automatic renumbering.

There is some convoluted discussion about how they wanted their /48 policy to 
somehow encourage residential ISPs to give their users more IP space in the 
base offering. I'm not sure why or what purpose an addressing policy should 
have to a business case. I see nothing motivating a residential ISP (especially 
one providing CPE equipment) to change their current deployment system one 
iota. And I'm pretty sure they are the ones MOST exposed to abuses of this 
address space by the least technical user base. (side note, if I were a 
residential ISP I'd configure a /64 to my highly-controlled CPE router and 
issue /128s to each and every device that plugged in on the customer site, and 
only one per MAC and have a remotely configurable limit of say 50 devices or 
whatever the mac table limit was. So I only have one route entry in my 
aggregation layer and if the customer blows his CPE router up, I'm still 
protected.)

Question - Whatever happened to the concept of a customer coming to their SP 
for more space? Why do we have to give them enough space for a decade of 
theoretical use when every week we could widen their subnet without causing any 
negative impact on them? No renumbering, etc. It's not considered a burden 
today, but under IP6 it is? Heck, since space is so plentiful, we can all set 
up gateways to do it automatically, but until routers get smarter, I don't see 
how all that dead routable space is a good thing.  Customers are paying for and 
getting a service, a continuous relationship with some set of SPs. In that 
service they aren't getting a mathematical representation, they are getting 
usable IP space, but that doesn't mean that if they hop out of bed in the 
middle of the night and decide to allocate 5,000,000 unique IPs the SP network 
should automatically accept it (based on today's current technology).

BOGONS, IP hijacks and all the rest seem like the worse problem here and the 
whole point of putting training wheels on these roll outs. Instead, it seems we 
are systematically unwinding all the lessons learned from CIDR and going back 
to addresses being classful, interface links being massive space wasters and no 
one caring about addresses. That's fine, and probably an improvement, until the 
next round of attacks and then shortages occur. Once the schools start teaching 
RFC3177, the hardcoded apps are sure to follow.

Deepak

RE: IPv6 - real vs theoretical problems

[Deepak Jain]

Thanks Grant,  I've already read this.  :)

I have no problem with enabling /64s for everyone/everything in the future, as 
the equipment capability increases, but right now there are real concerns about 
en masse deployment and the vulnerabilities we open our hardware to.

Which is why I was talking about reserving the larger block, but only allowing 
folks to have as much space as they can manage successfully and with a similar 
risk profile as they have today. Obviously it doesn't take too many people 
leaving their networks wide to cause a problem for the rest of us.

Best,

Deepak

From: Grant Phillips [mailto:grant.phill...@gwtp.id.au]
Sent: Thursday, January 06, 2011 5:47 PM
To: Deepak Jain
Cc: NANOG list
Subject: Re: IPv6 - real vs theoretical problems

Hi Deepak,

I acknowledge and see the point made. There is a lot of dead space in the IPv6 
world. Are we allowing history to repeat it self? Well i'm swaying more to no.

Have you read this RFC? This is pretty satisfying in making me feel more 
comfortable assigning out /48 and /64's. I can sleep at night now! :P

http://tools.ietf.org/html//rfc3177<http://tools.ietf.org/html/rfc3177>

Cheers,
Grant Phillips

On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain 
mailto:dee...@ai.net>> wrote:

Please, before you flame out, recognize I know a bit of what I am talking 
about. You can verify this by doing a search on NANOG archives. My point is to 
actually engage in an operational discussion on this and not insult (or be 
insulted).

While I understand the theoretical advantages of /64s and /56s and /48s for all 
kinds of purposes, *TODAY* there are very few folks that are actually using any 
of them. No typical customer knows what do to do (for the most part) with their 
own /48, and other than autoconfiguration, there is no particular advantage to 
a /64 block for a single server -- yet. The left side of the prefix I think 
people and routers are reasonably comfortable with, it's the "host" side that 
presents the most challenge.

My interest is principally in servers and high availability equipment (routers, 
etc) and other things that live in POPs and datacenters, so autoconfiguration 
doesn't even remotely appeal to me for anything. In a datacenter, many of these 
concerns about having routers fall over exist (high bandwidth links, high power 
equipment trying to do as many things as it can, etc).

Wouldn't a number of problems go away if we just, for now, follow the IPv4 
lessons/practices like allocating the number of addresses a customer needs --- 
say /122s or /120s that current router architectures know how to handle -- to 
these boxes/interfaces today, while just reserving /64 or /56 spaces for each 
of them for whenever the magic day comes along where they can be used safely?

As far as I can tell, this "crippling" of the address space is completely 
reversible, it's a reasonable step forward and the only "operational" loss is 
you can't do all the address jumping and obfuscation people like to talk 
about... which I'm not sure is a loss.

In your enterprise, behind your firewall, whatever, where you want autoconfig 
to work, and have some way of dealing with all of the dead space, more power to 
you. But operationally, is *anything* gained today by giving every host a /64 
to screw around in that isn't accomplished by a /120 or so?

Thanks,

DJ

Re: IPv6 - real vs theoretical problems

[Randy McAnally]

-- Original Message ---
From: Jeff Wheeler 
Sent: Thu, 6 Jan 2011 21:01:12 -0500

> Are there any large transit networks doing /64 on point-to-point
> networks to BGP customers?  Who are they?

Add HE.net to the list.

-Randy
www.fastserv.com

Re: IPv6 - real vs theoretical problems

[Devon True]

On 1/6/2011 9:01 PM, Jeff Wheeler wrote:
> Are there any large transit networks doing /64 on point-to-point
> networks to BGP customers?  Who are they?

Our Qwest and TW Telecom links are /64.

--
Devon

Re: IPv6 - real vs theoretical problems

[Tim Chown]

On 7 Jan 2011, at 06:11, Owen DeLong wrote:
> 
> That's a draft, and, it doesn't really eliminate the idea that /48s are 
> generally
> a good thing so much as it recognizes that there might be SOME circumstances
> in which they are either not necessary or insufficient.
> 
> As a draft, it hasn't been through the full process and shouldn't be 
> considered
> to have the same weight as an RFC.
> 
> While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, 
> indeed, may
> never do so.

The IETF data tracker shows draft-ietf-v6ops-3177bis-end-sites is under IESG 
review, with comments currently being made, see 
https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/
which also notes the draft has strong support so is likely to be published soon.

The document is only guidance regardless.

Tim

Re: IPv6 - real vs theoretical problems

[sthaug]

> Are there any large transit networks doing /64 on point-to-point
> networks to BGP customers?  Who are they?  What steps have they taken
> to eliminate problems, if any?

Our Global Crossing IPv6 transit is on a /64 Ethernet point-to-point.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 6, 2011, at 10:50 PM, Jima wrote:

> On 1/7/2011 12:11 AM, Owen DeLong wrote:
>> That's a draft, and, it doesn't really eliminate the idea that /48s are 
>> generally
>> a good thing so much as it recognizes that there might be SOME circumstances
>> in which they are either not necessary or insufficient.
>> 
>> As a draft, it hasn't been through the full process and shouldn't be 
>> considered
>> to have the same weight as an RFC.
>> 
>> While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, 
>> indeed, may
>> never do so.
> 
> Fully understood; I wasn't meaning to present it as irrefutable evidence that 
> the /64 & /48 mindset is flawed, but as a timely counterpoint to people 
> expounding the virtues of 3177 without cautiously acknowledging that its 
> recommendations aren't necessarily for everyone.  I apologize if my 
> intentions weren't terribly clear -- that may be a good cue for me to go to 
> bed.
> 
> Jima

I believe that the draft, even if it were to be adopted as is, does not intend 
to obsolete the /64, just the /48
recommendation in 3177.

Owen

Re: IPv6 - real vs theoretical problems

[Jima]

On 1/7/2011 12:11 AM, Owen DeLong wrote:

That's a draft, and, it doesn't really eliminate the idea that /48s are 
generally
a good thing so much as it recognizes that there might be SOME circumstances
in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered
to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, 
may
never do so.


 Fully understood; I wasn't meaning to present it as irrefutable 
evidence that the /64 & /48 mindset is flawed, but as a timely 
counterpoint to people expounding the virtues of 3177 without cautiously 
acknowledging that its recommendations aren't necessarily for everyone. 
 I apologize if my intentions weren't terribly clear -- that may be a 
good cue for me to go to bed.


 Jima

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 6, 2011, at 8:58 PM, Jima wrote:

> On 1/6/2011 4:47 PM, Grant Phillips wrote:
>> I acknowledge and see the point made. There is a lot of dead space in the
>> IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
>> to no.
>> 
>> Have you read this RFC? This is pretty satisfying in making me feel more
>> comfortable assigning out /48 and /64's. I can sleep at night now! :P
>> 
>> http://tools.ietf.org/html//rfc3177
> 
> I can't tell if you're trolling, or if you didn't get the memo from Monday.  
> I guess I'll lean toward the latter.
> 
> http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html
> 
> Jima

That's a draft, and, it doesn't really eliminate the idea that /48s are 
generally
a good thing so much as it recognizes that there might be SOME circumstances
in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered
to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, 
may
never do so.

Owen

Re: IPv6 - real vs theoretical problems

[Jima]

On 1/6/2011 4:47 PM, Grant Phillips wrote:

I acknowledge and see the point made. There is a lot of dead space in the
IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
to no.

Have you read this RFC? This is pretty satisfying in making me feel more
comfortable assigning out /48 and /64's. I can sleep at night now! :P

http://tools.ietf.org/html//rfc3177


 I can't tell if you're trolling, or if you didn't get the memo from 
Monday.  I guess I'll lean toward the latter.


http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html

 Jima

Re: IPv6 - real vs theoretical problems

[William Herrin]

On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain  wrote:
> Wouldn't a number of problems go away if we just, for now, follow the
> IPv4 lessons/practices like allocating the number of addresses a
> customer needs --- say /122s or /120s that current router
> architectures know how to handle -- to these boxes/interfaces
> today, while just reserving /64 or /56 spaces for each of them
> for whenever the magic day comes along where they can be
> used safely?

Hi Deepak,

No. IPv6 is only *almost* the same as IPv4. Drill these three
differences into your mind and you should do just fine:

/64 LAN netmask
nibble delegation boundary
how many LANs (not hosts!) in this stub network?

Without going into the technical details, IPv6 has been engineered
with the intention that any netmask will work but a /64 netmask works
distinctly better. Don't think of it as a 128 bit address. Think of it
as a 64 bit network address plus a 64 bit host address. Apply IPv4
lessons to the 64 bit network address. The 64 bit host address is for
the customer, the same way the 16-bit TCP port is for the customer.

IPv6 has been rigged so that address space naturally delegates on
nibble boundaries. It's one NS entry in the RDNS zone. It's an exact
string of characters in the hexadecimal written form. Should you
delegate on a different boundary, you invite all the common
difficulties human beings have evaluating a netmask and add in the
trouble dealing with base 16, rarely for any discernible gain.

In IPv4 you think about how many addresses do I need to accommodate X
hosts. This mental model does not match IPv6's technology model. If
LANs are always /64, how many LANs does this stub network require?


Example: Customer A has a gaming PC in a DMZ and two surfing PCs. How
many IPv6 addresses?

1 LAN (/64) for the DMZ
1 LAN (/64) for the PCs
1 LAN (/64) between the firewall and the router
round up to the nibble boundary: 16 LANs (/60)

Consider providing a /56 or a /48 instead of a /60 so that there's
lots of room for expansion, dynamic interior delegation or whatever.
But /60 is your absolute floor. Less will turn out to be like telling
the same customer to use 192.168.1.252/30: technical difficulties will
promptly ensue.

Regards,
Bill Herrin


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

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 6, 2011, at 2:00 PM, Deepak Jain wrote:

> 
> Please, before you flame out, recognize I know a bit of what I am talking 
> about. You can verify this by doing a search on NANOG archives. My point is 
> to actually engage in an operational discussion on this and not insult (or be 
> insulted).
> 
> While I understand the theoretical advantages of /64s and /56s and /48s for 
> all kinds of purposes, *TODAY* there are very few folks that are actually 
> using any of them. No typical customer knows what do to do (for the most 
> part) with their own /48, and other than autoconfiguration, there is no 
> particular advantage to a /64 block for a single server -- yet. The left side 
> of the prefix I think people and routers are reasonably comfortable with, 
> it's the "host" side that presents the most challenge.
> 
> My interest is principally in servers and high availability equipment 
> (routers, etc) and other things that live in POPs and datacenters, so 
> autoconfiguration doesn't even remotely appeal to me for anything. In a 
> datacenter, many of these concerns about having routers fall over exist (high 
> bandwidth links, high power equipment trying to do as many things as it can, 
> etc). 
> 
> Wouldn't a number of problems go away if we just, for now, follow the IPv4 
> lessons/practices like allocating the number of addresses a customer needs 
> --- say /122s or /120s that current router architectures know how to handle 
> -- to these boxes/interfaces today, while just reserving /64 or /56 spaces 
> for each of them for whenever the magic day comes along where they can be 
> used safely?
> 
No... A single perceived problem would go away and we would reacquire many many 
more problems that IPv6 is intended to leave behind.

So far, IPv6 scans have been few and far between. The ones we have seen have 
been short lived and haven't even scanned a single
network (Perhaps some time in the next 500+ years we will see one that does, 
but, I have my doubts).

I think that targeted or hinted scanning will be the more likely approach in 
the IPv6 world. We haven't yet seen what will happen in that
realm.

As to what we lose if we eliminate large sparse end networks, we lose the 
following advantages:

+   Ability to just add machines to a network without having to worry about 
resizing the network or
renumbering everything or worst of all adding yet another prefix to 
hold the new machines.

+   Sparse address density and privacy addressing capabilities

+   SLAAC

+   Simplified "network of things" capabilities

There are probably other things as well, but, those 4 are what I can think of 
off the top of my head.

Only the first one applies to server environments, but, it's a HUGE win for 
server environments, so, I think it's worth preserving for
that reason alone. However, if you're willing to abandon that for your server 
farm, then, nobody is stopping you, actually. IPv6
fully supports statically configured networks of any size down to /127. Knock 
yourself out.

> As far as I can tell, this "crippling" of the address space is completely 
> reversible, it's a reasonable step forward and the only "operational" loss is 
> you can't do all the address jumping and obfuscation people like to talk 
> about... which I'm not sure is a loss. 
> 
I'm not sure what you mean by "crippling" of the address space. It seems to be 
working just fine in a number of production
environments around the world, including both my work and home environments.

> In your enterprise, behind your firewall, whatever, where you want autoconfig 
> to work, and have some way of dealing with all of the dead space, more power 
> to you. But operationally, is *anything* gained today by giving every host a 
> /64 to screw around in that isn't accomplished by a /120 or so?
> 
I don't imagine anyone will give every host a /64. What is currently proposed 
is giving every network a /64. Most networks
contain at least two hosts to be minimally useful (router + end system), and 
the vast majority of those contain more than
one end system (3+ hosts).

Owen

Re: IPv6 - real vs theoretical problems

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 8:04 PM, Jimmy Hess  wrote:
> It is advisable to look for much stronger reasons than "With
> IPv4 we did it"  or   With IPv4 we ran into such and such
> problem"   due to unique characteristics of IPv4 addressing
> or other IPv4 conventions that had to continue to exist for
> compatibility reasons, etc, etc.

I certainly agree that there are many advantages to the greater
address space offered by IPv6.  I don't mean to advocate that we do
things the same way as was necessary to conserve v4 address space, and
I'm sure we all realize that RIR policies necessarily contributed to
routing table growth in trade for extending the life of the available
address space.

I'm not blindly deploying /64 networks, either.  Doing so with the
current set of problems, and lack of knobs, is very foolish.  My
transit providers offer a mix of /126 and /124 demarc subnets so far,
and /124 is what I choose to standardize on for my BGP customers and
private peering, for simplicity and convenience.  As I mentioned
before, I currently allocate a /64 and configure a /124, so I am not
painting myself into a corner either way.

How many of us with an appreciable level of expertise remain concerned
that our approach may need significant adjustment?  How many think we
know what those potential adjustments may be, and have planned to make
them easy (or transparent) for ourselves and customers if they become
necessary?  This is what is IMO most important to a responsible IPv6
deployment.  To do otherwise is inviting unpredictable future pain.

I am comforted by the fact that Level3 is deploying customer demarc
subnets as /126 and is NOT allocating a /64 for each, but are instead
packing them densely in an IPv4 /30 fashion.  They recognize problems
with the /64 approach, choose not to follow the "standard" to the
letter, and implement their dual-stack network in a way they
presumably believe is safe and scalable.  Large networks like Level3
choosing to insist that equipment vendors support this configuration,
rather than have problems with densely packed subnets smaller than
/64, will mean that anyone who wants to sell a router to Level3 had
better make it work correctly this way, which is good for the small
guy like me who thinks he will eventually transition to that
configuration.  Right now, I am still hedging my bet.

Are there any large transit networks doing /64 on point-to-point
networks to BGP customers?  Who are they?  What steps have they taken
to eliminate problems, if any?

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 - real vs theoretical problems

[Jimmy Hess]

On Thu, Jan 6, 2011 at 4:00 PM, Deepak Jain  wrote:
> Wouldn't a number of problems go away if we just, for now, follow the IPv4 
> lessons/practices like allocating the number of addresses a customer needs ---
> say /122s or /120s that current router architectures know how to handle -- to 
> these boxes/interfaces today, while just reserving /64 or /56 spaces for
> each of them for whenever the magic day comes along where they can be used 
> safely?

Trying to run the IPv6 network using IPv4 addressing practices is
similar to upgrading your horse and buggy
to a sports car, and insisting on driving this car only on dirt roads,
 avoiding pavements at all costs,  due to the danger
of slipping,  if that was the lesson you learned with
horses and buggies.

You can probably do it,  and survive,  but that does not mean it will
be advantageous trouble free, advisable, or fun.

In this case, you will bring all the negatives (and more) that the
practice had with IPv4,  for questionable or no advantages.

It is advisable to look for much stronger reasons than "With
IPv4 we did it"  or   With IPv4 we ran into such and such
problem"   due to unique characteristics of IPv4 addressing
or other IPv4 conventions that had to continue to exist for
compatibility reasons, etc, etc.


--
-JH

Re: IPv6 - real vs theoretical problems

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain  wrote:
> As far as I can tell, this "crippling" of the address space is completely 
> reversible, it's a reasonable step forward and the only "operational" loss is 
> you can't do all the address jumping and obfuscation people like to talk 
> about... which I'm not sure is a loss.

I largely agree with you, but my knowledge is similar to yours, and
does not extend to dealing with low-end CPE, dormitory LANs, hot
spots, or mobile networks.  I am by no means an authority in those
areas and I remain open to the possibility that there may be some
operational advantages to the IPv6 addressing concept for those users.
 The problem is there are very serious operational disadvantages for
you and I, but the standard tells us to do it anyway.  I would like
the hot spot or mobile guys to be able to choose /64 if they want to.
I need to choose otherwise, and customers expecting /64 as the
"standard" are going to be disappointed until the standard allows for
different choices.

I don't have an opinion on whether the address space is truly
"crippled."  If I did, I'm not sure it would be useful.  Classful
addressing ran out of gas in IPv4, so IPv6 has a huge number of bits
to hopefully avoid a repeat of that.  Okay, I can buy into that.
There are some major networks who aren't, though, and I think they
made a very conscious choice.  We won't know if it's a necessary
choice for a long time.

I will choose to devote my arguing-on-the-mailing-list time to topics
I think are more useful to discuss.  I do not think you will change
very many minds about IPv6 numbering schemes.  I hope I will change
some minds about the current safety of public /64 LANs and get more
folks talking to their vendors about it, which should give us some
kind of solution sooner, rather than later.  Choose your battles.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 - real vs theoretical problems

[Grant Phillips]

Hi Deepak,

I acknowledge and see the point made. There is a lot of dead space in the
IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
to no.

Have you read this RFC? This is pretty satisfying in making me feel more
comfortable assigning out /48 and /64's. I can sleep at night now! :P

http://tools.ietf.org/html//rfc3177

Cheers,
Grant Phillips

On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain  wrote:

>
> Please, before you flame out, recognize I know a bit of what I am talking
> about. You can verify this by doing a search on NANOG archives. My point is
> to actually engage in an operational discussion on this and not insult (or
> be insulted).
>
> While I understand the theoretical advantages of /64s and /56s and /48s for
> all kinds of purposes, *TODAY* there are very few folks that are actually
> using any of them. No typical customer knows what do to do (for the most
> part) with their own /48, and other than autoconfiguration, there is no
> particular advantage to a /64 block for a single server -- yet. The left
> side of the prefix I think people and routers are reasonably comfortable
> with, it's the "host" side that presents the most challenge.
>
> My interest is principally in servers and high availability equipment
> (routers, etc) and other things that live in POPs and datacenters, so
> autoconfiguration doesn't even remotely appeal to me for anything. In a
> datacenter, many of these concerns about having routers fall over exist
> (high bandwidth links, high power equipment trying to do as many things as
> it can, etc).
>
> Wouldn't a number of problems go away if we just, for now, follow the IPv4
> lessons/practices like allocating the number of addresses a customer needs
> --- say /122s or /120s that current router architectures know how to handle
> -- to these boxes/interfaces today, while just reserving /64 or /56 spaces
> for each of them for whenever the magic day comes along where they can be
> used safely?
>
> As far as I can tell, this "crippling" of the address space is completely
> reversible, it's a reasonable step forward and the only "operational" loss
> is you can't do all the address jumping and obfuscation people like to talk
> about... which I'm not sure is a loss.
>
> In your enterprise, behind your firewall, whatever, where you want
> autoconfig to work, and have some way of dealing with all of the dead space,
> more power to you. But operationally, is *anything* gained today by giving
> every host a /64 to screw around in that isn't accomplished by a /120 or so?
>
> Thanks,
>
> DJ
>
>
>
>

Re: IPv6 - real vs theoretical problems

[Jack Bates]

On 1/6/2011 4:00 PM, Deepak Jain wrote:

In your enterprise, behind your firewall, whatever, where you want
autoconfig to work, and have some way of dealing with all of the dead
space, more power to you. But operationally, is*anything*  gained
today by giving every host a /64 to screw around in that isn't
accomplished by a /120 or so?


Today, I still like SLAAC. All my servers support specifying tokens for 
the host portion of the prefix. Pre-config, many utilize traditional 
SLAAC and end up in a range which is stateful firewall protected by the 
routers until such time as I can renumber them into the appropriate range.


Anyways, ARIN just approved my new allocation and I have to go renumber 
all those servers. At least assigning the new IPv6 addresses only 
requires a quick router edit. Application changes will take longer, of 
course, since we don't automatically generate DNS and other nifties.


The helpdesk, home, and customer trial networks should hopefully 
renumber with easy per my last renumbering trial. Link addressing, 
loopback changes, BGP, etc in the routers will still be a PITA.



Jack