date:20111228

valdis.kletni...@vt.edu wrote:

 IPv6 does not work well in many environments.
 
 Feel free to try to deprecate *everything* that doesn't work well in many
 environments.

Why not?

 Heck, SMTP doesn't work well in many environments (it's done in
 cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc)

Red herring.

I thought all of us on some mailing list recognize SMTP working
well.

But, if you insist you don't, feel free not to use it, which means
you leave most, if not all, mailing lists including NANOG ones.

 It's one thing to deprecate something that's obviously a complete failure or
 has reached historic status - but RA isn't either of those *yet*.

That is not a valid counter argument against a proposal to
make RA deprecated, that is, make RA reach historic status.

 In this case, the following statement in RFC1883:
If the minimum time for rebooting the node is known (often more than
6 seconds),
 is the wrong assumption which made RA annoying.
 
 Oddly enough, a lot of us are running on networks where assuming this about 
 end
 user gear is perfectly reasonable.

That is because, as I wrote already in the previous mail,

   Network configuration was mostly stationary

For example, IPv6 might work well, if most of your end users
are not moving rapidly between small mobile cells.

However, assuming you change the cells every 100m in average
and you are moving at 100km/h, you must change the cells every
3.6 seconds in average, which means you must be able to change
the cells frequently, which means each cell change take a lot
less than 3.6 seconds.

 We haven't seen many consumer-grade
 Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds.

IPv6 is wrongly architected, not because it assumes nodes are
able to reboot in much under 6 seconds, but because it assumes
new configurations necessary only at boot time.

 Yes, I know you can do it with careful tuning and throwing SSDs and other
 hardware at it - doesn't mean it's common.

Obviously, the IPv6 committee and you are assuming computers
of immobile main frame computers or, at least, immobile
workstations.

However, in the real world, commonly available mobile phones
are IP capable computers which wake up from dormant state
within a second and needs handover often within a second.

Masataka Ohta

Re: IPv6 RA vs DHCPv6 - The chosen one?

Your straw man argument (which is what this has become) is just
dancing around the real issue.  You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).

You have yet to identify who (beyond yourself) is calling for RA to be
deprecated, though you made it sound like majority of the IETF was.

You have yet to identify the problems with the design of RA that
support that assertion.

Taking the position that a single statement is not a valid counter
argument against a proposal to make RA deprecated is weak at best; in
actuality it wasn't a counter argument at all, but rather a statement
exposing that you haven't presented an argument yet.  The burden of
proof lies with you, as you're the one calling for the deprecation of
RA.

So let's hear that, please (genuinely interested).




2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
 valdis.kletni...@vt.edu wrote:

 IPv6 does not work well in many environments.

 Feel free to try to deprecate *everything* that doesn't work well in many
 environments.

 Why not?

 Heck, SMTP doesn't work well in many environments (it's done in
 cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc)

 Red herring.

 I thought all of us on some mailing list recognize SMTP working
 well.

 But, if you insist you don't, feel free not to use it, which means
 you leave most, if not all, mailing lists including NANOG ones.

 It's one thing to deprecate something that's obviously a complete failure or
 has reached historic status - but RA isn't either of those *yet*.

 That is not a valid counter argument against a proposal to
 make RA deprecated, that is, make RA reach historic status.

 In this case, the following statement in RFC1883:
    If the minimum time for rebooting the node is known (often more than
    6 seconds),
 is the wrong assumption which made RA annoying.

 Oddly enough, a lot of us are running on networks where assuming this about 
 end
 user gear is perfectly reasonable.

 That is because, as I wrote already in the previous mail,

       Network configuration was mostly stationary

 For example, IPv6 might work well, if most of your end users
 are not moving rapidly between small mobile cells.

 However, assuming you change the cells every 100m in average
 and you are moving at 100km/h, you must change the cells every
 3.6 seconds in average, which means you must be able to change
 the cells frequently, which means each cell change take a lot
 less than 3.6 seconds.

 We haven't seen many consumer-grade
 Windows, Macs, or Linux boxes that are able to reboot in much under 6 
 seconds.

 IPv6 is wrongly architected, not because it assumes nodes are
 able to reboot in much under 6 seconds, but because it assumes
 new configurations necessary only at boot time.

 Yes, I know you can do it with careful tuning and throwing SSDs and other
 hardware at it - doesn't mean it's common.

 Obviously, the IPv6 committee and you are assuming computers
 of immobile main frame computers or, at least, immobile
 workstations.

 However, in the real world, commonly available mobile phones
 are IP capable computers which wake up from dormant state
 within a second and needs handover often within a second.

                                                Masataka Ohta




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: subnet prefix length 64 breaks IPv6?

On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum
iljit...@muada.com wrote:
 Also somehow the rule that all normal address space must use 64-bit interface
 identifiers found its way into the specs for no reason that I have ever been 
 able
 to uncover. On the other hand there's also the rule that IPv6 is classless and
 therefore routing on any prefix length must be supported, although for some
 implementations forwarding based on  /64 is  somewhat less efficient.

This ambiguity has always bothered me.  The address architecture RFC
requires a 64-bit interface identifier, but it's required to be
unenforced by implementation, which makes it more of a suggestion at
best.  I think the wording should be updated to changed MUST to
SHOULD.  That said, and despite my own use of prefix lengths other
than 64-bit, I do believe that a 64-bit prefix for each host network
is in our long-term interest.  Not having to size networks based on
the number of hosts is a good thing.  Features made possible by a
64-bit address space is a good thing.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

Iljitsch van Beijnum wrote:

 Just to clear up a few misconceptions:

Only to add yet another misconception without any clearing up?

 Router advertisements are exactly what the name suggests,
 routers advertising their presence.
 The first function of router advertisements is to tell
 hosts where the routers are,

OK, so far.

 so the hosts can install a default route.

WRONG.

Routers are not a default route.

If a host receives RAs only from a router, the host can do
nothing other than installing the router as the default
router. If not, however, the host must directly be involved
in IGP activities, or, the following end to end argument
is applicable:

The function in question can completely and correctly
be implemented only with the knowledge and help of
the application standing at the end points of the
communication system. Therefore, providing that
questioned function as a feature of the communication
system itself is not possible.

Masataka Ohta

PS

Granted that the notion of default router of IPv4 is no better
than that of IPv6.

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
 Granted that the notion of default router of IPv4 is no better
 than that of IPv6.

Please present a reasonable alternative.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 RA vs DHCPv6 - The chosen one?


Ray Soucy wrote:


Your straw man argument (which is what this has become) is just
dancing around the real issue.� You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).


No counter argument possible against such abstract nonsense.


You have yet to identify who (beyond yourself) is calling for RA to be
deprecated,


Tomas Podermanski wrote:

: from my perspective the short answer for this never-ending story is:

: - SLAAC/RA is totally useless, does not bring any benefit at all
:   and should be removed from IPv6 specs

: I personally prefer to bury SLAAC once forever for several reasons:

 though you made it sound like majority of the IETF was.

No, I didn't.

Masataka Ohta

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

Ray Soucy wrote:

 Granted that the notion of default router of IPv4 is no better
 than that of IPv6.
 
 Please present a reasonable alternative.

According to the end to end argument, the only possible solution
to the problem, with no complete or correct alternatives, is to
let hosts directly participate in IGP activities.

See the paper by Saltzer et. al.

Masataka Ohta

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Iljitsch van Beijnum

On 28 Dec 2011, at 13:26 , Ray Soucy wrote:

 Granted that the notion of default router of IPv4 is no better
 than that of IPv6.

 Please present a reasonable alternative.

Obviously reducing down the entire DFZ to a single default route is a bad case 
of premature optimization, which we all know is how so many engineering efforts 
get into trouble.

The right way to handle this would be for hosts to engage in both inter and 
intra domain routing with local routers, and then do their own aggregation if 
and when desired.

Iljitsch

PS.  :-)

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

Iljitsch van Beijnum wrote:

 Granted that the notion of default router of IPv4 is no better
 than that of IPv6.
 
 Please present a reasonable alternative.
 
 Obviously reducing down the entire DFZ to a single default route
 is a bad case of premature optimization,

Stop confusing default router and default route.

Masataka Ohta

Re: subnet prefix length 64 breaks IPv6?

 On the other hand there's also the rule that IPv6 is classless and therefore 
 routing on any prefix length must be supported, although for some 
 implementations forwarding based on  /64 is somewhat less efficient.

Can you please name names for the somewhat less efficient part? I've
seen this and similar claims several times, but the lack of specific
information is rather astounding.

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

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
 According to the end to end argument, the only possible solution
 to the problem, with no complete or correct alternatives, is to
 let hosts directly participate in IGP activities.

 See the paper by Saltzer et. al.

So your entire argument is based on an academic paper from 1981 and
that host systems should participate in IGP.

We tried that.

It didn't scale well.

The Internet today is very different than the Internet in 1981.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 RA vs DHCPv6 - The chosen one?

On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
 No counter argument possible against such abstract nonsense.

Yes.  That was my point.




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Glen Kent

Most vendors have a TCAM that by default does IPv6 routing for netmasks =64.

They have a separate TCAM (which is usually limited in size) that does
routing for masks 64 and =128.

TCAMs are expensive and increase the BOM cost of routers. Storing
routes with masks  64 takes up twice the number of TCAM entries as
the routes with masks = 64. Since IPv6 is *supposed* to work with /64
masks, most vendors (usually the not-so-expensive-routers) provide a
smaller TCAM for  /64 masks.

Glen

On Wed, Dec 28, 2011 at 6:40 PM,  sth...@nethelp.no wrote:
 On the other hand there's also the rule that IPv6 is classless and therefore 
 routing on any prefix length must be supported, although for some 
 implementations forwarding based on  /64 is somewhat less efficient.

 Can you please name names for the somewhat less efficient part? I've
 seen this and similar claims several times, but the lack of specific
 information is rather astounding.

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

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Ryan Malayter



On Dec 28, 7:10 am, sth...@nethelp.no wrote:
  On the other hand there's also the rule that IPv6 is classless and 
  therefore routing on any prefix length must be supported, although for some 
  implementations forwarding based on  /64 is somewhat less efficient.

 Can you please name names for the somewhat less efficient part? I've
 seen this and similar claims several times, but the lack of specific
 information is rather astounding.


Well, I do know if you look at the specs for most newer L3 switches,
they will often say something like max IPv4 routes 8192, max IPv6
routes 4096. This leads one to believe that the TCAMs/hash tables are
only using 64 bits for IPv6 forwarding, and therefores longer prefixes
must be handled in software.

This may very well not be true under the hood at all, but the fact
that vendors publish so little IPv6 specification and benchmarking
information doesn't help matters.

Re: subnet prefix length 64 breaks IPv6?

 Most vendors have a TCAM that by default does IPv6 routing for netmasks =64.
 
 They have a separate TCAM (which is usually limited in size) that does
 routing for masks 64 and =128.

Please provide references. I haven't seen any documentation of such an
architecture myself.

 TCAMs are expensive and increase the BOM cost of routers. Storing
 routes with masks  64 takes up twice the number of TCAM entries as
 the routes with masks = 64. Since IPv6 is *supposed* to work with /64
 masks, most vendors (usually the not-so-expensive-routers) provide a
 smaller TCAM for  /64 masks.

Ah, but do the not-so-expensive-routers use TCAM at all?

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

Re: subnet prefix length 64 breaks IPv6?

  Can you please name names for the somewhat less efficient part? I've
  seen this and similar claims several times, but the lack of specific
  information is rather astounding.
 
 Well, I do know if you look at the specs for most newer L3 switches,
 they will often say something like max IPv4 routes 8192, max IPv6
 routes 4096. This leads one to believe that the TCAMs/hash tables are
 only using 64 bits for IPv6 forwarding, and therefores longer prefixes
 must be handled in software.

It might lead you to believe so - however, I believe this would be
commercial suicide for hardware forwarding boxes because they would no
longer be able to handle IPv6 at line rate for prefixes needing more
than 64 bit lookups. It would also be an easy way to DoS such boxes...

 This may very well not be true under the hood at all, but the fact
 that vendors publish so little IPv6 specification and benchmarking
 information doesn't help matters.

Cisco actually has published quite a bit of info, e.g.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html

Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and
200 Mpps IPv6 with dCEF

They have also published EANTC tests which include IPv6 forwarding rates.

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

Re: IPv6 RA vs DHCPv6 - The chosen one?

I mean no disrespect.

What I meant by that post was that I look forward to reading something
along the lines of:

8

1. I believe RA should be moved to HISTORICAL status because of the
following concerns:

2. A better way to provide routing information to host systems would be:

8

This would be far more productive than arguing line-by-line against
other statements without presenting what exactly it is that your
arguing in favor of.

Give us the big picture.

After reading some of your work on end-to-end multihoming, I think I
understand some of what you're trying to say.  My problem is that
while you seem to have a very strong academic understanding of
networking, you seem to be ignoring operational realities in
implementation.




On Wed, Dec 28, 2011 at 8:22 AM, Ray Soucy r...@maine.edu wrote:
 On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta
 mo...@necom830.hpcl.titech.ac.jp wrote:
 No counter argument possible against such abstract nonsense.

 Yes.  That was my point.




 --
 Ray Soucy

 Epic Communications Specialist

 Phone: +1 (207) 561-3526

 Networkmaine, a Unit of the University of Maine System
 http://www.networkmaine.net/



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: subnet prefix length 64 breaks IPv6?

It's fairly common knowledge that most of our systems work on 64-bit
at best (and more commonly 32-bit still).

If every route is nicely split at the 64-bit boundary, then it saves a
step in matching the prefix. Admittedly a very inexpensive step.

I expect that most hardware and software implementations store IPv6 as
either a group of 4 32-bit integers or a pair of 64-bit integers, and
a [ 7 or ] 8-bit prefix length field. I haven't read anything about a
new 128-bit ASIC for IPv6, at least.

In this context, it is perfectly reasonable, and expected, that the
use of longer prefixes will have a higher cost.

However, I think the number of routes, and your network architecture
play a significant factor.

It is a fairly standard practice to have different routes for your WAN
connections (e.g. the routers you use BGP on and need to support
thousands of routes) than the routers you use internally, where the
routing table can be considerably smaller (and for which you can
summarize). For these routers, the cost of routing is generally a
non-factor as the tables are much smaller.

I think a greater concern than simple routing and forwarding, would be
additional services, such as queuing, or filtering. These may be
implemented in hardware when a 64-bit boundary is used, but punted to
CPU otherwise. Though this would be implementation specific and is
something you would want to research for whatever hardware you're
running.

So far, the biggest performance problem I've encountered is related to
neighbor discovery. It seems that in most implementations the
neighbor discovery process is implemented in software. It doesn't
have much to do with the boundary, but rather just that the process
(e.g. solicitation for unknown entries) is expensive enough that
sweeping through available address space can easily use all available
CPU capacity.

One [somewhat effective] solution to this is to attempt to use longer
prefixes so there is much less address space where such an attack
would be valid. It is much less costly for a router to discard a
packet that it has no route for than it is to issue thousands of
neighbor discovery solicitations per second.

There are a few solutions that vendors will hopefully look into. One
being to implement neighbor discovery in hardware (at which point
table exhaustion also becomes a legitimate concern, so the logic
should be such that known associations are not discarded in favor of
unknown associations).

I do think, despite these limitations, that hardware is quickly
catching up to IPv6, though. I don't think it will be long before we
see the major vendors have solid implementations. Some of them
already may; I haven't had a chance to play with the newest stuff out
there.

On Wed, Dec 28, 2011 at 9:50 AM, sth...@nethelp.no wrote:
Can you please name names for the somewhat less efficient part? I've
seen this and similar claims several times, but the lack of specific
information is rather astounding.

Well, I do know if you look at the specs for most newer L3 switches,
they will often say something like max IPv4 routes 8192, max IPv6
routes 4096. This leads one to believe that the TCAMs/hash tables are
only using 64 bits for IPv6 forwarding, and therefores longer prefixes
must be handled in software.

It might lead you to believe so - however, I believe this would be
commercial suicide for hardware forwarding boxes because they would no
longer be able to handle IPv6 at line rate for prefixes needing more
than 64 bit lookups. It would also be an easy way to DoS such boxes...

This may very well not be true under the hood at all, but the fact
that vendors publish so little IPv6 specification and benchmarking
information doesn't help matters.

Cisco actually has published quite a bit of info, e.g.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html

Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and
200 Mpps IPv6 with dCEF

They have also published EANTC tests which include IPv6 forwarding rates.

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

--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread TJ

2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp

 valdis.kletni...@vt.edu wrote:



 SNIP

  In this case, the following statement in RFC1883:
 If the minimum time for rebooting the node is known (often more than
 6 seconds),
  is the wrong assumption which made RA annoying.
 
  Oddly enough, a lot of us are running on networks where assuming this
 about end
  user gear is perfectly reasonable.

 That is because, as I wrote already in the previous mail,

Network configuration was mostly stationary

 For example, IPv6 might work well, if most of your end users
 are not moving rapidly between small mobile cells.

 However, assuming you change the cells every 100m in average
 and you are moving at 100km/h, you must change the cells every
 3.6 seconds in average, which means you must be able to change
 the cells frequently, which means each cell change take a lot
 less than 3.6 seconds.


To me, that sounds like an argument in favor of SLAAC.  SLAAC is noticeably
faster in my experience than DHCP (v4 or v6).  Also, RAs can be sent in the
ms range - for environments that expect that type of attachment-point-churn
...

Also:
Isn't 100m an arbitrarily tight range for a cel tower?
And for cellular, isn't the real churn happening more at the Layer2 side
... no L3/IPv6/IPv4 interaction?



  We haven't seen many consumer-grade
  Windows, Macs, or Linux boxes that are able to reboot in much under 6
 seconds.

 IPv6 is wrongly architected, not because it assumes nodes are
 able to reboot in much under 6 seconds, but because it assumes
 new configurations necessary only at boot time.


Boot time, or anytime a change in network attachment point is detected ...
is that not sufficient?


 Yes, I know you can do it with careful tuning and throwing SSDs and other
  hardware at it - doesn't mean it's common.

 Obviously, the IPv6 committee and you are assuming computers
 of immobile main frame computers or, at least, immobile
 workstations.

 However, in the real world, commonly available mobile phones
 are IP capable computers which wake up from dormant state
 within a second and needs handover often within a second.


Again, if we are arguing about simple speed of address attainment - SLAAC
wins.



 Masataka Ohta



/TJ

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Ryan Malayter



On Dec 28, 8:50 am, sth...@nethelp.no wrote:

 It might lead you to believe so - however, I believe this would be
 commercial suicide for hardware forwarding boxes because they would no
 longer be able to handle IPv6 at line rate for prefixes needing more
 than 64 bit lookups. It would also be an easy way to DoS such boxes...

That's just what I'm arguing here: no vendor info I've seen positively
says they *can* handle line-rate with longer IPv6 prefixes. The other
information available leads one to believe that all the published
specs are based on /64 prefixes.

Even a third-party test reports don't mention IPv6 or prefix length at
all:
http://www.aristanetworks.com/media/system/pdf/LippisTestReportMay2011.pdf

 Cisco actually has published quite a bit of info, e.g.

 http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod...

 Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and
 200 Mpps IPv6 with dCEF

 They have also published EANTC tests which include IPv6 forwarding rates.

Except nowhere in there is the prefix length for the test indicated,
and the exact halving of forwarding rate for IPv6 leads one to believe
that there are two TCAM lookups for IPv6 (hence 64-bit prefix lookups)
versus one for IPv4.

For example, what is the forwarding rate for IPv6 when the tables are
filled with /124 IPv6 routes that differ only in the last 60 bits?

Even then EANTC test results you reference make no mention of the
prefix length for IPv4 or IPv6, or even the number of routes in the
lookup table during the testing:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd800c958a.pdf

Re: subnet prefix length 64 breaks IPv6?

For what its worth I haven't stress tested it or anything, but I
haven't seen any evidence on any of our RSP/SUP 720 boxes that would
have caused me to think that routing and forwarding isn't being done
in hardware, and we make liberal use of prefixes longer than 64
(including 126 for every link network).  They might just be under
capacity to the point that I haven't noticed, though.  I have no
problem getting muti-gigabit IPv6 throughput.

On Wed, Dec 28, 2011 at 10:30 AM, Ryan Malayter malay...@gmail.com wrote:


 On Dec 28, 8:50 am, sth...@nethelp.no wrote:

 It might lead you to believe so - however, I believe this would be
 commercial suicide for hardware forwarding boxes because they would no
 longer be able to handle IPv6 at line rate for prefixes needing more
 than 64 bit lookups. It would also be an easy way to DoS such boxes...

 That's just what I'm arguing here: no vendor info I've seen positively
 says they *can* handle line-rate with longer IPv6 prefixes. The other
 information available leads one to believe that all the published
 specs are based on /64 prefixes.

 Even a third-party test reports don't mention IPv6 or prefix length at
 all:
 http://www.aristanetworks.com/media/system/pdf/LippisTestReportMay2011.pdf

 Cisco actually has published quite a bit of info, e.g.

 http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod...

 Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and
 200 Mpps IPv6 with dCEF

 They have also published EANTC tests which include IPv6 forwarding rates.

 Except nowhere in there is the prefix length for the test indicated,
 and the exact halving of forwarding rate for IPv6 leads one to believe
 that there are two TCAM lookups for IPv6 (hence 64-bit prefix lookups)
 versus one for IPv4.

 For example, what is the forwarding rate for IPv6 when the tables are
 filled with /124 IPv6 routes that differ only in the last 60 bits?

 Even then EANTC test results you reference make no mention of the
 prefix length for IPv4 or IPv6, or even the number of routes in the
 lookup table during the testing:
 http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd800c958a.pdf





-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: subnet prefix length 64 breaks IPv6?

 If every route is nicely split at the 64-bit boundary, then it saves a
 step in matching the prefix.  Admittedly a very inexpensive step.

My point here is that IPv6 is still defined as longest prefix match,
so unless you *know* that all prefixes are = 64 bits, you still need
the longer match.

 In this context, it is perfectly reasonable, and expected, that the
 use of longer prefixes will have a higher cost.

In a way I agree with you. However, if I put my purchasing hat on, I
would refuse to buy equipment that could only forward on the first 64
bits, *or* where the forwarding decision was much slower (hardware vs
software) for prefixes longer than 64 bits. I would not be surprised
if vendors decide that it is a *commercial* necessity to support full
128 bit matches.

 However, I think the number of routes, and your network architecture
 play a significant factor.

Absolutely. In our network by far the largest number of IPv6 prefixes
are EBGP prefixes in the 32 to 48 bit range. However, we also have for
instance our own 128 bit loopbacks - they are obviously only in our IGP.

 I think a greater concern than simple routing and forwarding, would be
 additional services, such as queuing, or filtering.  These may be
 implemented in hardware when a 64-bit boundary is used, but punted to
 CPU otherwise.  Though this would be implementation specific and is
 something you would want to research for whatever hardware you're
 running.

Again, that would be an excellent reason *not* to buy such equipment.

And yes, we know equipment that cannot *filter* on full IPv6 + port
number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my
original point was that I still haven't seen equipment with forwarding
problems for prefixes  64 bits. 

 There are a few solutions that vendors will hopefully look into.  One
 being to implement neighbor discovery in hardware (at which point
 table exhaustion also becomes a legitimate concern, so the logic
 should be such that known associations are not discarded in favor of
 unknown associations).

I'm afraid I don't believe this is going to happen unless neighbor
discovery based attacks become a serious problem. And even then it would
take a long time.

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

Re: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Leo Bicknell

In a message written on Wed, Dec 28, 2011 at 08:33:23PM +0900, Masataka Ohta 
wrote:
 However, assuming you change the cells every 100m in average
 and you are moving at 100km/h, you must change the cells every
 3.6 seconds in average, which means you must be able to change
 the cells frequently, which means each cell change take a lot
 less than 3.6 seconds.

Moble networks do not today, and should not in the future expose
those handoffs to the IP layer.  Even WiFi networks are moving from
the per-cell (AP) model you describe to a controller based
infrastructure that seeks to avoid exposing L3 changes to the client.

You do not want to get a new L3 address every 3.6 seconds.  Worse,
if in the case of VoIP you need a cell handoff to take  25ms or
so, which could never happen with new L3 addresseing and then
renegotating the session to a new L3 address.

Moble networks are designed to provide a L1/L2 fast switching path
back to a controller infrastructure which then provides the L3
handoff.  This properly decouples the layers and allows normal LAN
based timing for the L3 system.

The short version is, the cell to cell handoff time, or the cell
dwell time is irrelevant for any L3 addressing problem.

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


pgpBK8CCJfJmk.pgp
Description: PGP signature

Re: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Cameron Byrne

On Wed, Dec 28, 2011 at 7:28 AM, TJ trej...@gmail.com wrote:
 2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp

 valdis.kletni...@vt.edu wrote:



 SNIP

  In this case, the following statement in RFC1883:
     If the minimum time for rebooting the node is known (often more than
     6 seconds),
  is the wrong assumption which made RA annoying.
 
  Oddly enough, a lot of us are running on networks where assuming this
 about end
  user gear is perfectly reasonable.

 That is because, as I wrote already in the previous mail,

        Network configuration was mostly stationary

 For example, IPv6 might work well, if most of your end users
 are not moving rapidly between small mobile cells.

 However, assuming you change the cells every 100m in average
 and you are moving at 100km/h, you must change the cells every
 3.6 seconds in average, which means you must be able to change
 the cells frequently, which means each cell change take a lot
 less than 3.6 seconds.


 To me, that sounds like an argument in favor of SLAAC.  SLAAC is noticeably
 faster in my experience than DHCP (v4 or v6).  Also, RAs can be sent in the
 ms range - for environments that expect that type of attachment-point-churn
 ...

 Also:
 Isn't 100m an arbitrarily tight range for a cel tower?
 And for cellular, isn't the real churn happening more at the Layer2 side
 ... no L3/IPv6/IPv4 interaction?



Correct.  Cellular network mobility at the cell site level is all L1
and L2 magic.  GSM / UTMS / LTE will never engage in SLAAC churn as a
result of a normal mobility event.


  We haven't seen many consumer-grade
  Windows, Macs, or Linux boxes that are able to reboot in much under 6
 seconds.

 IPv6 is wrongly architected, not because it assumes nodes are
 able to reboot in much under 6 seconds, but because it assumes
 new configurations necessary only at boot time.


 Boot time, or anytime a change in network attachment point is detected ...
 is that not sufficient?


 Yes, I know you can do it with careful tuning and throwing SSDs and other
  hardware at it - doesn't mean it's common.

 Obviously, the IPv6 committee and you are assuming computers
 of immobile main frame computers or, at least, immobile
 workstations.

 However, in the real world, commonly available mobile phones
 are IP capable computers which wake up from dormant state
 within a second and needs handover often within a second.


 Again, if we are arguing about simple speed of address attainment - SLAAC
 wins.



                                                 Masataka Ohta



 /TJ

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Leo Bicknell

In a message written on Wed, Dec 28, 2011 at 10:19:54AM -0500, Ray Soucy wrote:
 If every route is nicely split at the 64-bit boundary, then it saves a
 step in matching the prefix.  Admittedly a very inexpensive step.
 
 I expect that most hardware and software implementations store IPv6 as
 either a group of 4 32-bit integers or a pair of 64-bit integers, and
 a [ 7 or ] 8-bit prefix length field.  I haven't read anything about a
 new 128-bit ASIC for IPv6, at least.
 
 In this context, it is perfectly reasonable, and expected, that the
 use of longer prefixes will have a higher cost.

The routers are already having to do a 128-bit lookup under the
hood.  Consider you have a /48 routed in your IGP (to keep things
simple).  When you look up the /48 in a router you will see it has
a next hop.  A 128 bit next hop.  This may be a link local, it may
be a global unicast (depending on your implementation).  This next
hop has to be resolved, in the case of Ethernet as an example to a 
48 bit MAC address.

So a typical forwarding step is already a two step process:

  Look up variable length prefix to get next hop.
  Look up 128 bit next hop to get forwarding information.

Once the vendor has built a 128-bit TCAM for step #2, there's no
reason not to use it for step #1 as well.  AFAIK, in all recent products
this is how all vendors handle the problem (at a high level).

Sadly, this is all a case where mind share is hobbled by a few early
adopter problems.  If you look at the first IPv6 images for platforms
like the Cisco 7500 (in the VIP-2 days) that hardware was built to
IPv4 criteria, and had 32 bit TCAM's.  To make IPv6 work they did
multiple TCAM lookups, some the simple 32 bits x 4, others fancy
things trying to guess prefix lengths that might likley be used.
All took a substantial line rate hit moving IPv6 as a result.

Those problems simply don't exist in modern gear.  Once products
were designed to support native IPv6 rational design decisions were
made.

I don't know of any _current generation_ core router that has any
performance difference based on prefix length.  That's why prefix length
isn't in the test criteria, it simply doesn't matter.

I say this as a proud user of /128's, /126's, and /112's in a
multi-vendor network, as well.

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


pgpkXGc59wgZX.pgp
Description: PGP signature

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Glen Kent


 So a typical forwarding step is already a two step process:

  Look up variable length prefix to get next hop.
  Look up 128 bit next hop to get forwarding information.

Wrong.

You only do a lookup once.

You look up a TCAM or a hash table that gives you the next hop for a route.

You DONT need to do another TCAM lookup to get the egress
encapsulation information.

You get the egress encapsulation after your TCAM lookup. It typically
gives you an index that stores this information. All routes pointing
to one nexthop will typically point to the same index.

 Once the vendor has built a 128-bit TCAM for step #2, there's no
 reason not to use it for step #1 as well.  AFAIK, in all recent products
 this is how all vendors handle the problem (at a high level).

You only use the TCAM for #1, not for #2.

Glen

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Ryan Malayter



On Dec 28, 9:44 am, Ray Soucy r...@maine.edu wrote:
 For what its worth I haven't stress tested it or anything, but I
 haven't seen any evidence on any of our RSP/SUP 720 boxes that would
 have caused me to think that routing and forwarding isn't being done
 in hardware, and we make liberal use of prefixes longer than 64
 (including 126 for every link network).  They might just be under
 capacity to the point that I haven't noticed, though.  I have no
 problem getting muti-gigabit IPv6 throughput.


You can get 10GbE *throughput* from a Linux box doing all forwarding
in software as well. That's easy when the packets are big and the
routing tables are small, and the hash tables all fit in high-speed
processor cache.

The general lack of deep information about how the switching and
routing hardware really works for IPv6 is my main problem. It's not
enough to make informed buying or design decisions. Unfortunately, I
have over the course of my career learned that a trust but verify
policy is required when managing vendors. Especially vendors that have
a near-monopoly market position.

The problem, of course, is that verifying this sort of thing with
realistic worst-case benchmarks requires some very expensive equipment
and a lot of time, which is why the lack of solid information from
vendors and 3rd-party testing labs is worrying.

Surely some engineers from the major switch/router vendors read the
NANOG list. Anybody care to chime in with we forward all IPv6 prefix
lengths in hardware for these product families?

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Valdis . Kletnieks

On Wed, 28 Dec 2011 21:56:19 +0900, Masataka Ohta said:

 According to the end to end argument, the only possible solution
 to the problem, with no complete or correct alternatives, is to
 let hosts directly participate in IGP activities.

That's only for hosts that are actively trying to communicate on more than one
interface at a time, and even then quite often the *actual* right answer isn't
run an IGP, it's insert static routes for the subnets you need to reach via
the other interface(*).

Meanwhile, out in the real world, 98% of actual  hosts have a *really* easy
routing decision - they can make a choice of any of one routers to reach the
destination.  If it's a laptop that has both a wireless and a wired connection
active, usually a simple prefer wired or prefer wireless is sufficient.

Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by
default?  If not, why does the net continue to function just fine without it?

Hmm.. Thought so.  Maybe an IGP on end hosts isn't quite as needed on
production networks as an academic paper from years ago might suggest.

(*) If you think I'm going to run an IGP on some of my file servers when
default route to the world out the public 1G interface, and 5 static routes
describing the private 10G network is actually the *desired* semantic because
if anybody re-engineers the 10G net enough to make me change the routes, I have
*other* things to change as well, like iptables entries and /etc/exports and so
on.  I don't *want* an IGP changing that stuff around wiithout the liveware
taking a meeting to discuss deployment of the change.




pgpmZpbgqoXGx.pgp
Description: PGP signature

Re: subnet prefix length 64 breaks IPv6?

I did look into this a bit before.

To be more specific:

IPv6 CEF appears to be functioning normally for prefixes longer than
64-bit on my 720(s).

I'm not seeing evidence of unexpected punting.

The CPU utilization of the software process that would handle IPv6
being punted to software, IPv6 Input, is at a steady %0.00 average
(with spikes up to 0.02%).




So there would seem to be at least one major platform that is OK.




On Wed, Dec 28, 2011 at 12:51 PM, Ryan Malayter malay...@gmail.com wrote:


 On Dec 28, 9:44 am, Ray Soucy r...@maine.edu wrote:
 For what its worth I haven't stress tested it or anything, but I
 haven't seen any evidence on any of our RSP/SUP 720 boxes that would
 have caused me to think that routing and forwarding isn't being done
 in hardware, and we make liberal use of prefixes longer than 64
 (including 126 for every link network).  They might just be under
 capacity to the point that I haven't noticed, though.  I have no
 problem getting muti-gigabit IPv6 throughput.


 You can get 10GbE *throughput* from a Linux box doing all forwarding
 in software as well. That's easy when the packets are big and the
 routing tables are small, and the hash tables all fit in high-speed
 processor cache.

 The general lack of deep information about how the switching and
 routing hardware really works for IPv6 is my main problem. It's not
 enough to make informed buying or design decisions. Unfortunately, I
 have over the course of my career learned that a trust but verify
 policy is required when managing vendors. Especially vendors that have
 a near-monopoly market position.

 The problem, of course, is that verifying this sort of thing with
 realistic worst-case benchmarks requires some very expensive equipment
 and a lot of time, which is why the lack of solid information from
 vendors and 3rd-party testing labs is worrying.

 Surely some engineers from the major switch/router vendors read the
 NANOG list. Anybody care to chime in with we forward all IPv6 prefix
 lengths in hardware for these product families?




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: subnet prefix length 64 breaks IPv6?

 IPv6 CEF appears to be functioning normally for prefixes longer than
 64-bit on my 720(s).
 
 I'm not seeing evidence of unexpected punting.
 
 The CPU utilization of the software process that would handle IPv6
 being punted to software, IPv6 Input, is at a steady %0.00 average
 (with spikes up to 0.02%).
 
 So there would seem to be at least one major platform that is OK.

And there are other platforms, e.g. Juniper M/MX/T, where there is no
concept of punt a packet to software to perform a forwarding decision.
The packet is either forwarded in hardware, or dropped. IPv6 prefixes 
64 bit are handled like any other IPv6 prefixes, i.e. they are forwarded
in hardware.

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

Re: Speed Test Results

2011-12-28 Thread Joel Maslak

On Fri, Dec 23, 2011 at 10:13 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
 If you want to understand the issue in detail, check out the report from
 MIT this year, written by Steve Bauer and available at
 http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurem
 ents.pdf.

They should have put a date on their paper, including when the
measurements were done.  It appears to me to have been done sometime
after or around June of 2010.

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Jeff Wheeler

On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy r...@maine.edu wrote:
 There are a few solutions that vendors will hopefully look into.  One
 being to implement neighbor discovery in hardware (at which point
 table exhaustion also becomes a legitimate concern, so the logic
 should be such that known associations are not discarded in favor of
 unknown associations).

Even if that is done you are still exposed to attacks -- imagine if a
downstream machine that is under customer control (not yours) has a
whole /64 nailed up on its Ethernet interface, and happily responds to
ND solicits for every address.  Your hardware table will fill up and
then your network has failed -- which way it fails depends on the
table eviction behavior.

Perhaps this is not covered very well in my slides.  There are design
limits here that cannot be overcome by any current or foreseen
technology.  This is not only about what is broken about current
routers but what will always be broken about them, in the absence of
clever work-arounds like limits on the number of ND entries allowed
per physical customer port, etc.

We really need DHCPv6 snooping and ND disabled for campus access
networks, for example.  Otherwise you could give out addresses from a
limited range in each subnet and use an ACL (like Owen DeLong suggests
for hosting environments -- effectively turning the /64 into a /120
anyway) but this is IMO much worse than just not configuring a /64.

On Wed, Dec 28, 2011 at 10:45 AM,  sth...@nethelp.no wrote:
 I'm afraid I don't believe this is going to happen unless neighbor
 discovery based attacks become a serious problem. And even then it would
 take a long time.

The vendors seem to range from huh? to what is everyone else
doing? to Cisco (the only vendor to make any forward progress at all
on this issue.)  I think that will change as this topic is discussed
more and more on public mailing lists, and as things like DHCPv6
snooping, and good behavior when ND is disabled on a subnet/interface,
begin to make their way into RFPs.

As it stands right now, if you want to disable the IPv6 functionality
(and maybe IPv4 too if dual-stacked) of almost any datacenter /
hosting company offering v6, it is trivial to do that.  The same is
true of every IXP with a v6 subnet.  I think once some bad guys figure
this out, they will do us a favor and DoS some important things like
IXPs, or a highly-visible ISP, and give the vendors a kick in the
pants -- along with operators who still have the /64 or bust
mentality, since they will then see things busting due to trivial
attacks.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

IPTV and ASM

2011-12-28 Thread Mike McBride

Anyone using ASM (versus SSM) for IPTV? If so why?

thanks,
mike

Re: IPTV and ASM

2011-12-28 Thread Marshall Eubanks

Dear Mike;

On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote:
 Anyone using ASM (versus SSM) for IPTV? If so why?


From what I understand, the answer is likely to be yes and the
reason is likely to be deployed equipment only
supports IGMP v2.

Regards
Marshall

 thanks,
 mike

Re: subnet prefix length 64 breaks IPv6?

You will always be exposed to attacks if you're connected to the Internet.

(Not really sure what you were trying to say there.)
My primary concerns are attacks originated from external networks.
Internal network attacks are a different issue altogether (similar to
ARP attacks or MAC spoofing), which require different solutions.

As previously discussed in a recent thread, the attack vector you
describe (in a service provider environment) can be mitigated though
architecture simply by effective CPE design (isolated link network to
CPE, L3 hand-off at CPE, with stateful packet inspection; and small or
link-local prefixes for link networks).  Thankfully, this isn't a
model that is anything new; many networks are already built in this
way.

The only point contested is the validity of longer-than 64-bit
prefixes; which I think I've spoken enough on.

Enterprise and Data Center environments have a different set of
[similar] concerns.  Which is where the most concern on exploitation
of ND and large prefixes comes into play.  I think most of us have
been at this for long enough to have given up on the
one-configuration-fits-all school of network design.  A stateful
firewall internally can be a strong tool to mitigate this attack
vector in such environments, depending on their size.  For networks
where a stateful firewall isn't practical, though, that is where
stronger router implementation comes into play.

The suggestion of disabling ND outright is a bit extreme.  We don't
need to disable ARP outright to have functional networks with a
reasonable level of stability and security.  The important thing is
that we work with vendors to get a set of tools (not just one) to
address these concerns.  As you pointed out Cisco has already been
doing quite a bit of work in this area, and once we start seeing the
implementations become more common, other vendors will more than
likely follow (at least if they want our business).

Maybe I'm just a glass-half-full kind of guy. ;-)

I think being able to use longer prefixes than 64-bit helps
considerably.  I think that seeing routers that can implement ND in
hardware (or at least limit its CPU usage), and not bump known
associations for unknown ones will help considerably.  Stateful
firewalls (where appropriate) will help considerably.  And L2 security
features (ND inspection with rate-limiting, RA guard, DHCPv6 snooping)
will all help -- considerably.  Combined, they make for an acceptable
solution by current standards.

As was also pointed out, though, many networks don't even implement
this level of security for IP internally; the difference is that many
of them haven't needed to for external attacks because of the
widespread use of NAT, stateful firewalls, and much smaller address
space.  That is a little different in the IPv6 world, and why there is
concern being expressed on this list.

The most important thing is that network operators are aware of these
issues, have a basic understanding of the implications, and are
provided with the knowledge and tools to address them.

This really isn't much different than IPv4.




On Wed, Dec 28, 2011 at 4:08 PM, Jeff Wheeler j...@inconcepts.biz wrote:
 On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy r...@maine.edu wrote:
 There are a few solutions that vendors will hopefully look into.  One
 being to implement neighbor discovery in hardware (at which point
 table exhaustion also becomes a legitimate concern, so the logic
 should be such that known associations are not discarded in favor of
 unknown associations).

 Even if that is done you are still exposed to attacks -- imagine if a
 downstream machine that is under customer control (not yours) has a
 whole /64 nailed up on its Ethernet interface, and happily responds to
 ND solicits for every address.  Your hardware table will fill up and
 then your network has failed -- which way it fails depends on the
 table eviction behavior.

 Perhaps this is not covered very well in my slides.  There are design
 limits here that cannot be overcome by any current or foreseen
 technology.  This is not only about what is broken about current
 routers but what will always be broken about them, in the absence of
 clever work-arounds like limits on the number of ND entries allowed
 per physical customer port, etc.

 We really need DHCPv6 snooping and ND disabled for campus access
 networks, for example.  Otherwise you could give out addresses from a
 limited range in each subnet and use an ACL (like Owen DeLong suggests
 for hosting environments -- effectively turning the /64 into a /120
 anyway) but this is IMO much worse than just not configuring a /64.

 On Wed, Dec 28, 2011 at 10:45 AM,  sth...@nethelp.no wrote:
 I'm afraid I don't believe this is going to happen unless neighbor
 discovery based attacks become a serious problem. And even then it would
 take a long time.

 The vendors seem to range from huh? to what is everyone else
 doing? to Cisco (the only vendor to make any forward progress at

Re: IPTV and ASM

2011-12-28 Thread Mike McBride

Marshall,

On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks
marshall.euba...@gmail.com wrote:
 Dear Mike;

 On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote:
 Anyone using ASM (versus SSM) for IPTV? If so why?


 From what I understand, the answer is likely to be yes and the
 reason is likely to be deployed equipment only
 supports IGMP v2.

Agreed. I'm seeking confirmation, from IPTV implementers, that non
igmpv3 support is the reason for using ASM with IPTV. Versus other
reasons such as reducing state. Or is this a non issue and everyone is
using SSM with IPTV?

thanks,
mike

 Regards
 Marshall

 thanks,
 mike

Re: subnet prefix length 64 breaks IPv6?

2011-12-28 Thread Jeff Wheeler

On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy r...@maine.edu wrote:
 The suggestion of disabling ND outright is a bit extreme.  We don't
 need to disable ARP outright to have functional networks with a
 reasonable level of stability and security.  The important thing is

I don't think it's at all extreme.  If you are dealing with an access
network where DHCPv6 is the only legitimate way to get an address on a
given LAN segment, there is probably no reason for the router to use
ND to learn about neighbor L3L2 associations.  With DHCPv6 snooping
the router can simply not use ND on that segment, which eliminates
this problem.  However, this feature is not yet available.

It would also be difficult to convince hosting customers to use a
DHCPv6 client to populate their gateway's neighbor table.  However, if
this feature comes along before other fixes, it will be a good option
for safely deploying /64s without ND vulnerabilities.

 that we work with vendors to get a set of tools (not just one) to
 address these concerns.  As you pointed out Cisco has already been
 doing quite a bit of work in this area, and once we start seeing the
 implementations become more common, other vendors will more than
 likely follow (at least if they want our business).

 Maybe I'm just a glass-half-full kind of guy. ;-)

I think your view of the Cisco work is a little optimistic. :)  What
they have done so far is simply acknowledge that, yes, ND exhaustion
is a problem, and give the customer the option to mitigate damage to
individual interfaces / VLANs, on the very few platforms that support
the feature.

Cisco has also given the SUP-2T independent policers for ARP and ND,
so if you have a SUP-2T instead of a SUP720 / RSP720, your IPv4 won't
break when you get an IPv6 ND attack.  Unfortunately, there are plenty
of people out there who are running IPv6 /64s on SUP720s, most who do
not know that an attacker can break all their IPv4 services with an
IPv6 ND attack.

 The most important thing is that network operators are aware of these
 issues, have a basic understanding of the implications, and are
 provided with the knowledge and tools to address them.

We certainly agree here.  I am glad the mailing list has finally moved
from listening to Owen DeLong babble about this being a non-problem,
to discussing what work-arounds are possible, disadvantages of them,
and what vendors can do better in the future.

My personal belief is that DHCPv6 snooping, with ND disabled, will be
the first widely-available method of deploying /64s safely to
customer LAN segments.  I'm not saying this is good but it is a
legitimate solution.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

Notifying customers of upstream modifications

2011-12-28 Thread Andy Susag

Hi All,

 

Just a quick question for those of you running ISPs with BGP
downstreams.

 

If you add or remove an upstream provider to your network, do you
provide notification to your downstream customers? Likely, it would
cause a shift in their traffic. If they are peering with multiple ISPs
themselves, they may see a traffic flux. 

 

I know for a fact that our upstreams do not notify us of events so we
tend to not send out these sort of notifications. Just wonder what
everyone else does or if anyone happens to know best practice

 

Thanks,

Andy

Re: subnet prefix length 64 breaks IPv6?

As much as I argue with Owen on-list, I still enjoy reading his input.

It's a little uncalled for to be so harsh about his posts.  A lot of
us are strong-willed here, and many of us read things we've posted in
the past and ask what was I thinking, that's ridiculous; and perhaps
I'm just saying that because I do so more than most.

But really, let's stay civil.

I don't disagree with your other comments much, but I do think (hope
actually) that DHCPv6 snooping will not filter link-local traffic.
That would be a job for an ND inspection kind of technology, and one I
would hope was configurable.  There is no DHCPv6 for link-local so it
would be kind of silly to have DHCPv6 snooping restrict that traffic
completely.  It will be a little less straight forward than DHCP
snooping is, no doubt.

And I will admit I can be a Cisco fanboy at times, but only because
they've consistently been able to deliver on IPv6 more that other
vendors I've worked with.  Like any vendor it can be hard to get
through to the people who matter, but Cisco has been pretty good at
responding to us when we poke them on these matters.  Surprisingly,
most of the time the delay is waiting on a standard to be established
so they can implement that rather than their own thing.

On Wed, Dec 28, 2011 at 5:39 PM, Jeff Wheeler j...@inconcepts.biz wrote:
 On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy r...@maine.edu wrote:
 The suggestion of disabling ND outright is a bit extreme.  We don't
 need to disable ARP outright to have functional networks with a
 reasonable level of stability and security.  The important thing is

 I don't think it's at all extreme.  If you are dealing with an access
 network where DHCPv6 is the only legitimate way to get an address on a
 given LAN segment, there is probably no reason for the router to use
 ND to learn about neighbor L3L2 associations.  With DHCPv6 snooping
 the router can simply not use ND on that segment, which eliminates
 this problem.  However, this feature is not yet available.

 It would also be difficult to convince hosting customers to use a
 DHCPv6 client to populate their gateway's neighbor table.  However, if
 this feature comes along before other fixes, it will be a good option
 for safely deploying /64s without ND vulnerabilities.

 that we work with vendors to get a set of tools (not just one) to
 address these concerns.  As you pointed out Cisco has already been
 doing quite a bit of work in this area, and once we start seeing the
 implementations become more common, other vendors will more than
 likely follow (at least if they want our business).

 Maybe I'm just a glass-half-full kind of guy. ;-)

 I think your view of the Cisco work is a little optimistic. :)  What
 they have done so far is simply acknowledge that, yes, ND exhaustion
 is a problem, and give the customer the option to mitigate damage to
 individual interfaces / VLANs, on the very few platforms that support
 the feature.

 Cisco has also given the SUP-2T independent policers for ARP and ND,
 so if you have a SUP-2T instead of a SUP720 / RSP720, your IPv4 won't
 break when you get an IPv6 ND attack.  Unfortunately, there are plenty
 of people out there who are running IPv6 /64s on SUP720s, most who do
 not know that an attacker can break all their IPv4 services with an
 IPv6 ND attack.

 The most important thing is that network operators are aware of these
 issues, have a basic understanding of the implications, and are
 provided with the knowledge and tools to address them.

 We certainly agree here.  I am glad the mailing list has finally moved
 from listening to Owen DeLong babble about this being a non-problem,
 to discussing what work-arounds are possible, disadvantages of them,
 and what vendors can do better in the future.

 My personal belief is that DHCPv6 snooping, with ND disabled, will be
 the first widely-available method of deploying /64s safely to
 customer LAN segments.  I'm not saying this is good but it is a
 legitimate solution.

 --
 Jeff S Wheeler j...@inconcepts.biz
 Sr Network Operator  /  Innovative Network Concepts




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Doug Barton

On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
 However, this has two issues. First, with RAs there are no risks that
 incorrect default information is propagated because the default
 gateway itself broadcasts its presence.

Unless you have a malicious user on the network in which case all
traffic immediately switches to the malicious user's gateway. This is in
contrast to DHCP where the similar attack only affects new/renewing
hosts. I'm aware that SEND is trying to solve this problem, but it's not
yet deployed.

 With DHCP, it is possible to
 inject incorrect information. In my opinion, people are
 underestimating the problems that occur with IPv4 DHCP and the
 additional issues that would be introduced in IPv6 by adding this
 feature.

I think that people already know of and have solutions for the security
issues that exist for DHCP today.

 Second, publishing specifications, implementing them and waiting for
 users to adopt them takes a very, very long time. For DHCPv6 support,
 the time from first publication (2003) until wide availability (2011)
 has been 8 years. Are we ready to live in a half-baked world for
 another half a decade or more just so we can add this feature, while
 layer 2 filtering and VLANs more easily support similar
 functionality?

10-12 years ago I attempted to make 2 points to the IPv6 literati. First
that IPv6 would not be widely adopted in the enterprise until it had
full DHCP parity with v4. Second that the easiest way to do that would
be to declare all existing DHCPv4 options that are relevant to IPv6 as
existing in DHCPv6 by fiat, and to prevent new v6-only options from
using option numbers that already exist for v4 (and vice versa). I was
laughed out of the room on both counts. (If anyone wants more of the
history, see
https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html)

The good news is that it's not too late to fix DHCPv6. We're at a
watershed moment where it's just possible that we'll get the ability to
assign a default gateway added to it due to, for lack of a better term,
market forces. This would be a major paradigm shift. As you point out
the development lead time on stuff like that is rather painful, however
if we took advantage of the camel's nose under the tent and included
everything relevant that DHCPv4 can do in that update, we'd be in a
pretty good condition in a year or so.


Doug

-- 

You can observe a lot just by watching. -- Yogi Berra

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

Re: Notifying customers of upstream modifications

2011-12-28 Thread Michael Butler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/28/11 17:59, Andy Susag wrote:

 If you add or remove an upstream provider to your network, do you
 provide notification to your downstream customers? Likely, it would
 cause a shift in their traffic. If they are peering with multiple ISPs
 themselves, they may see a traffic flux. 
 
 I know for a fact that our upstreams do not notify us of events so we
 tend to not send out these sort of notifications. Just wonder what
 everyone else does or if anyone happens to know best practice

In an ideal world, part of a good change-management process is to notify
those who may see differences as a consequence of any proposed change
(tell the folk that care). That way, they know something is moving and
can plan accordingly. Also they can advise in a timely fashion if it
either works or not and make their own changes when appropriate.

Sadly, we do not live in an ideal world :-(

imb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk77pqUACgkQQv9rrgRC1JKChgCeOaZ4mlcZ8OzaHdeJGL8JF4B4
vooAnje3JgJLqecM1Q4SQ3F2GqP+Uhvj
=hUhW
-END PGP SIGNATURE-

Re: IPTV and ASM

2011-12-28 Thread Jeff Tantsura

Mike,

To my knowledge in most today's networks even if legacy equipment don't support 
IGMPv3 most likely 1st hop router does static translation and SSM upstream.
The reason not to migrate to SSM is usually - ASM is already there and works 
just fine :)
Cost to support RP infrastructure is usually the main non-technical factor to 
not to use ASM.
Would be interested to hear from the SPs on the list.

Regards,
Jeff

On Dec 28, 2011, at 2:19 PM, Mike McBride mmcbri...@gmail.com wrote:

 Marshall,
 
 On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks
 marshall.euba...@gmail.com wrote:
 Dear Mike;
 
 On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote:
 Anyone using ASM (versus SSM) for IPTV? If so why?
 
 
 From what I understand, the answer is likely to be yes and the
 reason is likely to be deployed equipment only
 supports IGMP v2.
 
 Agreed. I'm seeking confirmation, from IPTV implementers, that non
 igmpv3 support is the reason for using ASM with IPTV. Versus other
 reasons such as reducing state. Or is this a non issue and everyone is
 using SSM with IPTV?
 
 thanks,
 mike
 
 Regards
 Marshall
 
 thanks,
 mike

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread TJ

On Wed, Dec 28, 2011 at 18:16, Doug Barton do...@dougbarton.us wrote:

 On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
  However, this has two issues. First, with RAs there are no risks that
  incorrect default information is propagated because the default
  gateway itself broadcasts its presence.

 Unless you have a malicious user on the network in which case all
 traffic immediately switches to the malicious user's gateway. This is in
 contrast to DHCP where the similar attack only affects new/renewing
 hosts. I'm aware that SEND is trying to solve this problem, but it's not
 yet deployed.


Right, the window is tighter for DHCPv4 as compared to SLAAC.
That is why RA Guard is a really useful thing we should support to prevent
accidental maliciousness, and perhaps enhance RA Guard to account for
more skillful evasive (fragmented, etc.) malicious RAs.

In the former case, a simple ARP-spoofing attack (for IPv6, ND spoofing)
and you are back in ... but that is a separate paragraph :).


 With DHCP, it is possible to
  inject incorrect information. In my opinion, people are
  underestimating the problems that occur with IPv4 DHCP and the
  additional issues that would be introduced in IPv6 by adding this
  feature.

 I think that people already know of and have solutions for the security
 issues that exist for DHCP today.


And what is the percentage of environments that use those things?  (From
personal experience, 0% ... although certainly it is higher than that.)
 And yet, their IPv4 networks are up  running just fine ... In the big
picture, this has always been fairly low on the scale.  Make RA Guard a
norm for host ports and move forward.



  Second, publishing specifications, implementing them and waiting for
  users to adopt them takes a very, very long time. For DHCPv6 support,
  the time from first publication (2003) until wide availability (2011)
  has been 8 years. Are we ready to live in a half-baked world for
  another half a decade or more just so we can add this feature, while
  layer 2 filtering and VLANs more easily support similar
  functionality?

 10-12 years ago I attempted to make 2 points to the IPv6 literati. First
 that IPv6 would not be widely adopted in the enterprise until it had
 full DHCP parity with v4. Second that the easiest way to do that would
 be to declare all existing DHCPv4 options that are relevant to IPv6 as
 existing in DHCPv6 by fiat, and to prevent new v6-only options from
 using option numbers that already exist for v4 (and vice versa). I was
 laughed out of the room on both counts. (If anyone wants more of the
 history, see
 https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html)

 The good news is that it's not too late to fix DHCPv6. We're at a
 watershed moment where it's just possible that we'll get the ability to
 assign a default gateway added to it due to, for lack of a better term,
 market forces. This would be a major paradigm shift. As you point out
 the development lead time on stuff like that is rather painful, however
 if we took advantage of the camel's nose under the tent and included
 everything relevant that DHCPv4 can do in that update, we'd be in a
 pretty good condition in a year or so.


And, FWIW, I support making DHCPv6 more complete as well.
(Although, annoying to some, I don't mind DHCPv6 waiting for the M bit to
be sent in an RA - again separate paragraph!)


/TJ

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Brandon Butterworth

 facts deleted

 Second, publishing specifications, implementing them and waiting for
 users to adopt them takes a very, very long time. For DHCPv6 support,
 the time from first publication (2003) until wide availability (2011)
 has been 8 years. Are we ready to live in a half-baked world for
 another half a decade or more just so we can add this feature

enterprise:

  but you want us to do v6 today, why didn't you put it in
   when there was time then. Let us know when it's ready, ktnxbye

 I would like to make the following suggestion: rather than having
 DHCPv6 impose a default gateway with all the issues that that
 creates, why not implement a router preference option. This way,
 DHCPv6 can be used to select the correct default gateway from
 the list of possible default gateways that announce their presence
 through RAs

sounds like the which half of the baby would you like option.

I don't have a dog in this fight but understand the dhcp only option
is so the dhcp guys manage * and don't have to talk to the router
guys other than to tell them to fix the router when it breaks.

brandon

Re: IPTV and ASM

2011-12-28 Thread Glen Kent

SSM is also used since we *know* the IP addresses of the content
servers that are the sources - You dont need ASM. I dont think
maintaining RP infrastructure is trivial. Who wants to deal with
register packets, etc. Small routers punt all registers to CPU and
them forward them in SW.

In fact there was a draft which proposed using MPLS encapsulation in
networks that support MPLS to replace the existing RP mechanism.

http://tools.ietf.org/html/draft-bhatia-pim-mpls-register-packets-00

From the draft:

   Encapsulation and Decapsulation are expensive operations for routers
   and the latter, especially, as it entails a double lookup that many
   routers cannot do in hardware.  It is for this reason that several
   off the shelf chips do not support decapsulating the PIM Register
   packets.  Any router that cannot decapsulate the PIM Register packet
   in hardware must send all this traffic to CPU, where its
   decapsulated, and forwarded based on the multicast forwarding table.
   This increases the load on the CPU and also makes the router
   susceptible for DoS attacks.  Also, since Register packets are
   unicast, then can be easily spoofed and an attacker can use this to
   attack the router and thus the network.

   This document attempts to solve the above problems by doing away with
   the PIM Register packets.  It instead proposes using an MPLS tunnel
   to send all multicast data traffic till an SPT is formed.  This
   eliminates the complexity of decapsulating PIM register packets on
   the RP as it now only needs to pop off the MPLS labels before
   forwarding the native packet down the RPT.

Looks like the draft died some time back ..

Glen

On Thu, Dec 29, 2011 at 5:02 AM, Jeff Tantsura
jeff.tants...@ericsson.com wrote:
 Mike,

 To my knowledge in most today's networks even if legacy equipment don't 
 support IGMPv3 most likely 1st hop router does static translation and SSM 
 upstream.
 The reason not to migrate to SSM is usually - ASM is already there and works 
 just fine :)
 Cost to support RP infrastructure is usually the main non-technical factor to 
 not to use ASM.
 Would be interested to hear from the SPs on the list.

 Regards,
 Jeff

 On Dec 28, 2011, at 2:19 PM, Mike McBride mmcbri...@gmail.com wrote:

 Marshall,

 On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks
 marshall.euba...@gmail.com wrote:
 Dear Mike;

 On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote:
 Anyone using ASM (versus SSM) for IPTV? If so why?


 From what I understand, the answer is likely to be yes and the
 reason is likely to be deployed equipment only
 supports IGMP v2.

 Agreed. I'm seeking confirmation, from IPTV implementers, that non
 igmpv3 support is the reason for using ASM with IPTV. Versus other
 reasons such as reducing state. Or is this a non issue and everyone is
 using SSM with IPTV?

 thanks,
 mike

 Regards
 Marshall

 thanks,
 mike

Re: IPTV and ASM

2011-12-28 Thread Keegan Holley

Isn't source discovery and efficiency a big concern for ASM?  If individual
streams are tied to a specific source then it's possible to live without
some of the overhead involved in ASM.  Joins go straight to the source,
traffic is disseminated via direct paths instead of being replicated by the
RP, etc etc..

Disclaimer: Other than being a lab rat I haven't done much with multicast
in the wild.


2011/12/29 Jeff Tantsura jeff.tants...@ericsson.com

 Mike,

 To my knowledge in most today's networks even if legacy equipment don't
 support IGMPv3 most likely 1st hop router does static translation and SSM
 upstream.
 The reason not to migrate to SSM is usually - ASM is already there and
 works just fine :)
 Cost to support RP infrastructure is usually the main non-technical factor
 to not to use ASM.
 Would be interested to hear from the SPs on the list.

 Regards,
 Jeff

 On Dec 28, 2011, at 2:19 PM, Mike McBride mmcbri...@gmail.com wrote:

  Marshall,
 
  On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks
  marshall.euba...@gmail.com wrote:
  Dear Mike;
 
  On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com
 wrote:
  Anyone using ASM (versus SSM) for IPTV? If so why?
 
 
  From what I understand, the answer is likely to be yes and the
  reason is likely to be deployed equipment only
  supports IGMP v2.
 
  Agreed. I'm seeking confirmation, from IPTV implementers, that non
  igmpv3 support is the reason for using ASM with IPTV. Versus other
  reasons such as reducing state. Or is this a non issue and everyone is
  using SSM with IPTV?
 
  thanks,
  mike
 
  Regards
  Marshall
 
  thanks,
  mike

Re: IPv6 RA vs DHCPv6 - The chosen one?


Ray Soucy wrote:


After reading some of your work on end-to-end multihoming, I think I
understand some of what you're trying to say.  My problem is that
while you seem to have a very strong academic understanding of
networking, you seem to be ignoring operational realities in
implementation.


To your surprise, my opinion is partially based on my
experience about 10 years ago as a CTO of a commercial
ISP, which offered secure public WLAN service with IP
moblity.

Security and mobility stacks were implemented on BSD and
Windows.

We successfully performed smooth handover experiment at a
racing circuit with a car moving at 260km/h.

http://www.root-hq.com/newsrelease/news030513.html
(in Japanese)

which is why I know delay caused by SLAAC is annoying.

Though no commercial IPv6 service was offered, we received
government funding and implemented end to end multihoming
with mobility over IPv6 without ND. Public trial was offered:

http://www.root-hq.com/e/newsrelease/pressrels0218.html
(in English)

Masataka Ohta

Re: Notifying customers of upstream modifications

2011-12-28 Thread Tom Hill

Hi Andy,

On Wed, 2011-12-28 at 17:59 -0500, Andy Susag wrote:
 If you add or remove an upstream provider to your network, do you
 provide notification to your downstream customers? Likely, it would
 cause a shift in their traffic. If they are peering with multiple ISPs
 themselves, they may see a traffic flux. 

We raised this question recently. The answer (from those with seniority)
was that we sell IP transit. We do not specify where it comes from or
how it's made; beyond what a sales person may say to clinch a sale, the
contract does not mention our upstreams, only that we agree to transit
traffic to/from their ASN at an agreed rate per mbit.

The point came that if anyone whom requires BGP transit also *requires*
the fastest possible connectivity to a particular ASN (3356, 20940,
etc.) then they can always buy transit/peer with that ASN separately. In
most cases, this would also be preferable to taking blended tier-1
transit from a tier-2 (or however you describe that.)

 I know for a fact that our upstreams do not notify us of events so we
 tend to not send out these sort of notifications. Just wonder what
 everyone else does or if anyone happens to know best practice

*cough* Cogent. Perfect example. Automagic
de-peer^H^H^H^H^H^H^Hblack-holing happens without prior warning,
notification OR explanation.

And it's the same answer. We buy transit, we don't specify whom they
must be connected to. 

Morally I agree that it would be nice to tell your customers.
Practically, I don't believe you can win. I mean, would you tell your
downstreams every time you bring-up a new peer? That's not _always_
going to be positive for them.

The answer, speaking as a downstream and a transit provider, is to just
peer where you need guaranteed connectivity. If change is a problem to
your customers, they don't understand how BGP works and they need to cut
out the middle-man.

Tom

Re: IPv6 RA vs DHCPv6 - The chosen one?

I would like to understand how you think RA is broken, and how you
think that it could be improved.

You have made some bold statements, but we lack the context to
understand their meaning.




On Wed, Dec 28, 2011 at 7:11 PM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
 Ray Soucy wrote:

 After reading some of your work on end-to-end multihoming, I think I
 understand some of what you're trying to say.  My problem is that
 while you seem to have a very strong academic understanding of
 networking, you seem to be ignoring operational realities in
 implementation.


 To your surprise, my opinion is partially based on my
 experience about 10 years ago as a CTO of a commercial
 ISP, which offered secure public WLAN service with IP
 moblity.

 Security and mobility stacks were implemented on BSD and
 Windows.

 We successfully performed smooth handover experiment at a
 racing circuit with a car moving at 260km/h.

        http://www.root-hq.com/newsrelease/news030513.html
        (in Japanese)

 which is why I know delay caused by SLAAC is annoying.

 Though no commercial IPv6 service was offered, we received
 government funding and implemented end to end multihoming
 with mobility over IPv6 without ND. Public trial was offered:

        http://www.root-hq.com/e/newsrelease/pressrels0218.html
        (in English)

                                                Masataka Ohta



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 RA vs DHCPv6 - The chosen one?

TJ wrote:

 However, assuming you change the cells every 100m in average
 and you are moving at 100km/h, you must change the cells every
 3.6 seconds in average, which means you must be able to change
 the cells frequently, which means each cell change take a lot
 less than 3.6 seconds.

 To me, that sounds like an argument in favor of SLAAC.  SLAAC is noticeably
 faster in my experience than DHCP (v4 or v6).

RA initiated DHCPv6 is slower than RA, of course.

Note that RA initiated DHCPv6 is even required to suffer
from DAD delay.

 Also, RAs can be sent in the ms range

Only when you are using mobile IPv6 and there still remains
delay caused by DAD.

 Also:
 Isn't 100m an arbitrarily tight range for a cel tower?

Cell size must shrink as bandwidth requirements of mobile
devices increase.

 And for cellular, isn't the real churn happening more at the Layer2 side
 ... no L3/IPv6/IPv4 interaction?

Because of large amount of traffic caused by smart phones,
mobile providers, at least those in Japan, are trying to
bypass traffic from 3G to WLAN/Internet with IPv4 L3.

 Boot time, or anytime a change in network attachment point is detected ...
 is that not sufficient?

It is wrong to assume intervals between changes 6 seconds.

In general, ND is wrong to specify link specific timings
assuming infrequent changes.

Masataka Ohta

Re: IPv6 RA vs DHCPv6 - The chosen one?

Leo Bicknell wrote:

 Moble networks do not today, and should not in the future expose
 those handoffs to the IP layer.  Even WiFi networks are moving from
 the per-cell (AP) model you describe to a controller based
 infrastructure that seeks to avoid exposing L3 changes to the client.

The reality in Japan today is that each AP used by smart
phones to bypass traffic from 3G to the Internet is
independently provided by small shops or individuals'
households through their own Internet connectivity, there
can be no central controller.

 You do not want to get a new L3 address every 3.6 seconds.  Worse,
 if in the case of VoIP you need a cell handoff to take  25ms or
 so, which could never happen with new L3 addresseing and then
 renegotating the session to a new L3 address.

As voice traffic is negligible, I think it is carried over
3G only.

But, if you seriously need smooth handover, you must have
2 independent WLAN receivers to simultaneously connect to
two APs operating at different channels for make-before-break
style handover. Or, another possibility is to use only a single
channel of WLAN by all the related APs (Packet Division
Multiple Access (PDMA)).

I have confirmed both approaches work combined with IP mobility
with applications of voice and video over IP.

 Moble networks are designed to provide a L1/L2 fast switching path
 back to a controller infrastructure which then provides the L3
 handoff.  This properly decouples the layers and allows normal LAN
 based timing for the L3 system.

What's happening today is migration from 3G/4G to WLAN.

Masataka Ohta

Re: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread TJ

2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp

 TJ wrote:

  However, assuming you change the cells every 100m in average
  and you are moving at 100km/h, you must change the cells every
  3.6 seconds in average, which means you must be able to change
  the cells frequently, which means each cell change take a lot
  less than 3.6 seconds.

  To me, that sounds like an argument in favor of SLAAC.  SLAAC is
 noticeably
  faster in my experience than DHCP (v4 or v6).

 RA initiated DHCPv6 is slower than RA, of course.


I am not counting the delay caused by waiting for the RA against DHCPv6.

Isn't the stateless operation of a router providing a prefix in a RA always
going to be faster than statefully providing an address via DHCPv6 (even
with rapid commit enabling 2 messages to suffice; and noting that normally
DHCPv6 involves 4 messages and relaying)?

Note that RA initiated DHCPv6 is even required to suffer from DAD delay.

  Also, RAs can be sent in the ms range

 Only when you are using mobile IPv6 and there still remains delay caused
 by DAD.


I would say that it is only possible on platforms that support it.  You are
not required to enable mobile anything in order to set
the advertisement interval to be that tight.  And regardless of the
specified interval setting, a node sending a RS and getting back a RA is
still faster than the 4-way (default) message (which may require relaying)
exchange required for DHCP ... In either case, yes, DAD must happen ...
although Optimistic DAD can help there, or perhaps other link specific
solutions.



  Also:
  Isn't 100m an arbitrarily tight range for a cel tower?

 Cell size must shrink as bandwidth requirements of mobile
 devices increase.


Understandable, but down to the 100m range?
*(Partially tongue in cheek pre-response to your next statement: And why
should they bother, if the users can just hop onto WiFi? :)   )*

 And for cellular, isn't the real churn happening more at the Layer2 side
  ... no L3/IPv6/IPv4 interaction?

 Because of large amount of traffic caused by smart phones,
 mobile providers, at least those in Japan, are trying to
 bypass traffic from 3G to WLAN/Internet with IPv4 L3.


I applaud the apparent easy access to (open?) WiFi ... and the user
expecting that to work seemlessly, at speed.


 Boot time, or anytime a change in network attachment point is detected ...
  is that not sufficient?

 It is wrong to assume intervals between changes 6 seconds.


Again, IMHO, that has been addressed where relevant (IIRC, Cisco supports
down to advertising every 20ms; and solicited RAs happen 'as needed').  For
the enterprise side, even 6s is way too often and I believe most agree that
this aspect isn't a problem.


In general, ND is wrong to specify link specific timings
 assuming infrequent changes.


In principle I agree, but assumptions must be made somewhere or nothing can
get done.  If there is a change required to make it work, do so - the IPv6
over Foo RFCs are a good place to specify preferred values for $Foo.


/TJ

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

valdis.kletni...@vt.edu wrote:

 According to the end to end argument, the only possible solution
 to the problem, with no complete or correct alternatives, is to
 let hosts directly participate in IGP activities.
 
 That's only for hosts that are actively trying to communicate on more than one
 interface at a time,

Note that the end to end argument has the following
statement I omitted to quote:

(Sometimes an incomplete version of the function provided
by the communication system may be useful as a performance
enhancement.)

That is, there are incomplete solutions by intermediate systems
which sometimes work.

 and even then quite often the *actual* right answer isn't
 run an IGP, it's insert static routes for the subnets you need to reach via
 the other interface(*).

With manual configuration, you can do anything. But, aren't we
talking about autoconfiguration?

 If it's a laptop that has both a wireless and a wired connection
 active, usually a simple prefer wired or prefer wireless is
 sufficient.

Usually? Can you see the word complete in the end to end argument?

 Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by
 default?

Sanity check with Windows? Are you sure?

 If not, why does the net continue to function just fine without it?

It is often incomplete and incorrect unnecessarily requiring
manual reconfigurations.

 (*) If you think I'm going to run an IGP on some of my file servers when
 default route to the world out the public 1G interface, and 5 static routes
 describing the private 10G network is actually the *desired* semantic because
 if anybody re-engineers the 10G net enough to make me change the routes, I 
 have
 *other* things to change as well, like iptables entries and /etc/exports and 
 so
 on.  I don't *want* an IGP changing that stuff around wiithout the liveware
 taking a meeting to discuss deployment of the change.

If you are saying SLAAC is not enough in your case with
complicated manual management, I don't think I have to
argue against you on how to simplify it.

Masataka Ohta

Re: Notifying customers of upstream modifications

2011-12-28 Thread Keegan Holley

Most transit networks have some sort of blanket notification that they can
send to customers.  Something like between 12AM and 6AM sometime next week
you may or may not have a moderate or severe impact, but we're not going to
give you details.  It also depends on the peering that is being added or
removed.  The larger providers are mostly static.  I can't imagine Level 3
permanently depeering from Verizon for example.  Also, if paths change but
latency and hop count are still acceptable most customers will not notice
the change.  The same goes for outages.  Also, where do you draw the line.
For example if someone severs a peering with a content network like google
some of their downstreams will care others will not.  If ISP's notified
everyone of every change it would more or less become spam so I can see an
argument for both.  In large transit networks it probably comes down to the
predicted impact of the a particular change versus visibility and
contractual liabilities.


2011/12/28 Andy Susag asu...@ifncom.net

 Hi All,



 Just a quick question for those of you running ISPs with BGP
 downstreams.



 If you add or remove an upstream provider to your network, do you
 provide notification to your downstream customers? Likely, it would
 cause a shift in their traffic. If they are peering with multiple ISPs
 themselves, they may see a traffic flux.



 I know for a fact that our upstreams do not notify us of events so we
 tend to not send out these sort of notifications. Just wonder what
 everyone else does or if anyone happens to know best practice



 Thanks,

 Andy

Re: IPv6 RA vs DHCPv6 - The chosen one?

TJ wrote:

 RA initiated DHCPv6 is slower than RA, of course.

 I am not counting the delay caused by waiting for the RA against DHCPv6.

Do you count random delay between RA and DHCPv6 solicit?

Do you count DAD delay after DHCPv6?

 Isn't the stateless operation of a router providing a prefix in a RA always
 going to be faster than statefully providing an address via DHCPv6 (even
 with rapid commit enabling 2 messages to suffice; and noting that normally
 DHCPv6 involves 4 messages and relaying)?

As the stateless operation is actually stateful to keep address
assignment states by all the related nodes, DAD is required to
confirm the state is consistent, which means delay.

With DHCP only, there is no DAD necessary.

 Only when you are using mobile IPv6 and there still remains delay caused
 by DAD.

 I would say that it is only possible on platforms that support it.  You are
 not required to enable mobile anything in order to set
 the advertisement interval to be that tight.

Can I? I'm refering to RFC3775:

   One method which can provide for faster movement detection, is to
   increase the rate at which unsolicited Router Advertisements are
   sent.  Mobile IPv6 relaxes this limit such that routers MAY send
   unsolicited multicast Router Advertisements more frequently.

which is applicable only to MIPv6 routers.

 In either case, yes, DAD must happen ...
 although Optimistic DAD can help there,

The straight forward solution is to remove DAD along with stateful
SLAAC.

 or perhaps other link specific solutions.

A link specific solution is DHCPv6 without RA.

 Cell size must shrink as bandwidth requirements of mobile
 devices increase.

 Understandable, but down to the 100m range?

It is also a typical range for WLAN.

 *(Partially tongue in cheek pre-response to your next statement: And why
 should they bother, if the users can just hop onto WiFi? :)   )*

Moving users should be able to keep hopping onto WLANs.

 In general, ND is wrong to specify link specific timings
 assuming infrequent changes.

 In principle I agree, but assumptions must be made somewhere or nothing can
 get done. If there is a change required to make it work, do so - the IPv6
 over Foo RFCs are a good place to specify preferred values for $Foo.

The fundamental problem of ND is that it tries to be the only
way to have IPv6 over all the possible link layers. Instead
of having IPv6 uber Alles, the wrong goal of ND uber Alles
was targeted.

So, if we give up the goal to have IPv6 over Foo, there is
no reason to insist on ND uber Alles.

Masataka Ohta

Re: IPTV and ASM

2011-12-28 Thread Antonio Querubin


On Wed, 28 Dec 2011, Marshall Eubanks wrote:


From what I understand, the answer is likely to be yes and the
reason is likely to be deployed equipment only
supports IGMP v2.


That and numerous clients which don't know anything about SSM.

Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Christopher Morrow

On Wed, Dec 28, 2011 at 6:16 PM, Doug Barton do...@dougbarton.us wrote:
 On 12/28/2011 03:13, Iljitsch van Beijnum wrote:

 Second, publishing specifications, implementing them and waiting for
 users to adopt them takes a very, very long time. For DHCPv6 support,
 the time from first publication (2003) until wide availability (2011)
 has been 8 years. Are we ready to live in a half-baked world for
 another half a decade or more just so we can add this feature, while
 layer 2 filtering and VLANs more easily support similar
 functionality?

 10-12 years ago I attempted to make 2 points to the IPv6 literati. First
 that IPv6 would not be widely adopted in the enterprise until it had
 full DHCP parity with v4. Second that the easiest way to do that would

+1000

 be to declare all existing DHCPv4 options that are relevant to IPv6 as
 existing in DHCPv6 by fiat, and to prevent new v6-only options from
 using option numbers that already exist for v4 (and vice versa). I was
 laughed out of the room on both counts. (If anyone wants more of the

similarly folks keep laughing (or at least harumphing loudly) when
enterprise folk say: Hey, I use dhcp today for a large number of
things, I can't NOT use it going forward, support the features in v4
dhcp that I use in your new v6 thingy.

anyway, it seems to be getting slightly better, bolting more crud on
ND so you can continue to say: Yea, but you SHOULD use  is
wasted breath.

-chris

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

2011-12-28 Thread Valdis . Kletnieks

On Thu, 29 Dec 2011 11:51:00 +0900, Masataka Ohta said:
 valdis.kletni...@vt.edu wrote:
  Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled 
  by
  default?

 Sanity check with Windows? Are you sure?

It's a quick sanity check to this statment:

 According to the end to end argument, the only possible solution
 to the problem, with no complete or correct alternatives, is to
 let hosts directly participate in IGP activities.

If it's the only possible spolution, how come 99.8% of the end nodes
do just fine without it? Oh yeah..

 Note that the end to end argument has the following
 statement I omitted to quote:

   (Sometimes an incomplete version of the function provided
   by the communication system may be useful as a performance
   enhancement.)

 That is, there are incomplete solutions by intermediate systems
 which sometimes work.

For sometimes == 99.8% of the net.

 If you are saying SLAAC is not enough in your case with
 complicated manual management, I don't think I have to
 argue against you on how to simplify it.

It got simplfied with a handful of static routes and no IGP and no SLAAC
and no DHCP of any flavor. ;)


pgpiwXdenhdbx.pgp
Description: PGP signature

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?