OT: Sign of the Coming Apocalypse

[Jay Ashworth]

(that's next winter, right?)

I've just seen a TV ad for Duke Nukem Forever, in a Hulu airing of 
The Daily Show.

Cheers,
-- jr 'Finally??' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: The stupidity of trying to "fix" DHCPv6

[Iljitsch van Beijnum]

On 15 jun 2011, at 7:33, Owen DeLong wrote:

> Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS 
> vendors to make changes
> because experience has shown that they are more willing to do so than 
> vertical software vendors.

> As such, yes, I'd like to see some harmless extensions added to DHCPv6 that 
> solve some real world
> problems.

BTW, as long as you're making harmless changes: not putting a hard line end 
just _after_ 80 characters would make your messages easier to read.

As established before, all of this is not harmless and OS vendors (not sure 
what you're talking about with BIOS) aren't all that willing to make changes, 
at least not on short timescales.

It seems to me that the easiest solution to work around broken IPv4-only 
software isn't messing with the IPv6 protocol stack, but to create an IPv4 
overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite 
going through IPv6 routers.

Actually this would also be quite useful in hosting environments where it would 
be easy to give every IPv6 customer their own VLAN but the IPv4 subnets are 
entangled.

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 5:50 PM, Ricky Beam wrote:

> On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong  wrote:
>> The point of /64 is to support automatic configuration and incredibly sparse 
>> host addressing.
>> It is not intended to create stupidly large broadcast domains.
> 
> Several IETF (and NANOG) discussions say otherwise.  While current hardware 
> doesn't handle thousands of hosts, the protocol was designed for a future 
> where that's not true. (there's a future where *everything* is network 
> enabled... microwave oven, doorbell, weed whacker, everything.)
> 
Sure, but, that future still doesn't need stupidly large numbers of hosts on a 
common link.

>> A /22 is probably about the upper limit of a sane broadcast domain, but, 
>> even with a /22
>> or 1022 nodes max, each sending a packet every 10 seconds you don't get to 
>> 100s of PPS,
>> you get 102.2pps.
> 
> As I said, DHCP isn't the only source of traffic.  Setup a 1000 node network 
> today (just IPv4), and you will see a great deal of broadcast traffic (unless 
> those nodes aren't doing anything.)  With IPv6, it's all multicast (v6 
> doesn't have a "broadcast address") hinged on switches filtering the traffic 
> away from where it doesn't need to be.  The all-too-common Best Buy $20 white 
> box ethernet switch does no multicast filtering at all.  Pretty much all 
> wireless hardware sucks at multicast - period.  These are not things that can 
> be fixed with a simple software update... if the silicon doesn't do it, *it 
> doesn't do it*.

Depends on a number of factors. Yes, there are lots of issues. However, they 
aren't caused
by the small number of additional packets from DHCP.

Owen

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 6:00 PM, Ricky Beam wrote:

> On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum  
> wrote:
>> BTW, does this broken software run over IPv6, anyway?
> 
> Poorly designed network plus poorly designed software... I don't know which 
> chicken came first, and it doesn't matter.
> 
> IPv6 is totally different barnyard.  Build the v6 network properly -- one 
> gateway (one router, vrrp, whatever) -- and retool the software properly.  
> IPv6 doesn't have a broadcast address; as such if the software is setup to 
> use an appropriate multicast target (presumably in "user defined" space), 
> then it'll talk to exactly the right machines, and it's routable.
> 
> --Ricky

Sounds great, but, sometimes proprietary vertical software is a lot harder to 
move forward than
you might think.

Owen

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 3:44 PM, Iljitsch van Beijnum wrote:

> On 15 jun 2011, at 0:05, Owen DeLong wrote:
> 
>> Yes, the right solution would be to at least separate the VLANs and clean up 
>> this
>> mess. However, due to software packages that need to talk to each other over
>> common local broadcast across that boundary, this isn't possible in this 
>> particular
>> organization (don't get me started on the bad software, but, that's what 
>> there is.)
> 
> Strange that you don't apply the logic of "the existing software is what 
> there is" to the code deep inside hundreds of millions of hosts, but rather 
> to obscure stuff that presumably hardly anyone uses.
> 
> If changing this software is so hard, what these people need is some 
> filtering switches so the application multicasts get forwarded but the IP 
> provisioning multicasts don't. No standards action required.
> 
> BTW, does this broken software run over IPv6, anyway?

No, but, it require the v4 stack on the hosts to be on the same link, which 
means that the v6 stack will also be on the same link.

There are less broken scenarios, too.

Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS 
vendors to make changes
because experience has shown that they are more willing to do so than vertical 
software vendors.

As such, yes, I'd like to see some harmless extensions added to DHCPv6 that 
solve some real world
problems.

Owen

RE: So... is it time to do IPv6 day monthy yet?

[Ryan Finnesey]

I think this would be helpful.

Cheers
Ryan


-Original Message-
From: Ryan Pavely [mailto:para...@nac.net] 
Sent: Wednesday, June 08, 2011 11:08 AM
To: nanog@nanog.org
Subject: Re: So... is it time to do IPv6 day monthy yet?

I was thinking the same thing.  Good call :)

   Ryan Pavely
Net Access Corporation
http://www.nac.net/


On 6/8/2011 10:40 AM, Jay Ashworth wrote:
> It certainly sounds like it might be.
>
> Cheers,
> -- jra
>

RE: Thank you Microsoft (and others)

[Ryan Finnesey]

Hi Chris

Does Azure support IPv6 at this time?

Cheers
Ryan


-Original Message-
From: Christopher Palmer [mailto:christopher.pal...@microsoft.com] 
Sent: Friday, June 10, 2011 2:20 PM
To: Murphy, Jay, DOH; Jared Mauch; Shahid Shafi
Cc: NANOG list
Subject: RE: Thank you Microsoft (and others)

Thank you for the thanks :)

We'll be leaving the www.xbox.com web properties online indefinitely. We're 
holding on other properties but are moving forward at a brisk pace.

Best,
Chris

-Original Message-
From: Murphy, Jay, DOH [mailto:jay.mur...@state.nm.us]
Sent: Friday, June 10, 2011 9:49 AM
To: Jared Mauch; Shahid Shafi
Cc: NANOG list
Subject: RE: Thank you Microsoft (and others)

I've been saved by the sound of Microsoft.

~Jay
"We move the information that moves your world." 
“Engineering is about finding the sweet spot between what's solvable and what 
isn't."
“Good engineering demands that we understand what we’re doing and why, keep an 
open mind, and learn from experience.”


Radia Perlman


 
P Please consider the environment before printing e-mail


-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net]
Sent: Wednesday, June 08, 2011 7:20 PM
To: Shahid Shafi
Cc: NANOG list
Subject: Thank you Microsoft (and others)

I think it's important to thank Microsoft for leaving sites like xbox IPv6 
enabled.  Hope many other participants leave it on as well.

I think it's a certain sign of the maturity of the protocol and networks at 
this stage of the game.

I have observed some traffic step-down in the network, but it's not entirely 
clear if it's lowered to levels pre-v6-day.

Looking forward to those sharing data at NANOG next week.  (I'm not convinced 
the data I have is worth sharing, but will send it over to the nanogpc soon 
enough..)

- Jared

On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote:

> I dont think ISOC dashboard is updating any more. Google is no longer 
> advertising  but dashboard still shows green and TTLs were short 
> on those records.

Re: The stupidity of trying to "fix" DHCPv6

[Joel Jaeggli]

On Jun 13, 2011, at 5:41 PM, Owen DeLong wrote:

> 
> On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote:
> 
>> On 12 jun 2011, at 15:45, Leo Bicknell wrote:
>> 
 Like I said before, that would pollute the network with many multicasts 
 which can seriously degrade wifi performance.
>> 
>>> Huh?  This is no worse than IPv4 where a host comes up and sends a
>>> subnet-broadcast to get DHCP.
>> 
>> The IPv4 host does this once and gets its lease. If there is no DHCPv6 
>> server then DHCPv6 clients would keep broadcasting forever. Not a good thing.
>> 
> 
> Which is no worse than the behavior of an IPv4 host on a network without a 
> DHCP server.

An ipv4 host will in most cases configure itself with a link-local address. A 
possibly surprising number of people consider this broken, when in fact it's 
working. the possiblity that autoconfiguration of networks would occur when no 
routers or dhcp servers exist has some utility just as it did when windows 
started doing this with ipv4 circa 1998.

> Owen
> 
> 
> 

RE: The stupidity of trying to "fix" DHCPv6

[Dave Edelman]

> > BTW, does this broken software run over IPv6, anyway?
> 
> Poorly designed network plus poorly designed software... I don't know
which
> chicken came first, and it doesn't matter.
> 
> IPv6 is totally different barnyard.  Build the v6 network properly -- one
> gateway (one router, vrrp, whatever) -- and retool the software properly.
> IPv6 doesn't have a broadcast address; as such if the software is setup to
use
> an appropriate multicast target (presumably in "user defined" space), then
> it'll talk to exactly the right machines, and it's routable.
> 
When I was young and the earth was still cooling, I attended my very first
University level Computer and Information Science lecture. There was the
normal administatrivia followed by a discussion of how lucky we were to be
in the generation of programmers who would address the Year 2K problem. Just
to set expectations that was 1969 (okay the earth was actually getting
warmer) more than three decades before the event. Somehow I remember a bit
of a scramble to get everything ready on the evening. 

Fast forward a few years and a bunch of us are going to see a very similar
event, foretold well in advance and not addressed until  the last minute.
The parallels are amazing, many very large corporations will need to fix
(notice the future tense) a ton of software that is not IPv6 ready and the
last time any of it was reviewed was for Y2K and that guy is long since gone
and it is written in a language that no one understands and testing will
require at least one of each type of environment (IPv4, IPv6, Dual-Stack,
ArcNet ^H^H^H^H^H^H)


--Dave

(How many sick days do I have left?)

Re: The stupidity of trying to "fix" DHCPv6

[Brett Watson]

On Jun 10, 2011, at 7:03 PM, Owen DeLong wrote:

> I see no reason that additional DHCPv6 options would have to fragment the 
> installed
> base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think 
> that
> adding these options could allow for a set of rules that would be acceptable 
> to all
> and would allow administrators to make choices based on the needs of their
> environments.

Indeed, and agreed. I've got a number of large, multi-national enterprise 
customers who are in this very situation, they need the options because they're 
trying to get away from a lot of nasty, inherited, legacy configurations. The 
only way they can safely migrate from those is if we (well, IETF, via RFC, and 
then vendors) provide them the options to be flexible.

This thread is somewhat like the DLV/DNSSEC thread on dns-operations. Some are 
arguing DLV should die, but frankly it's giving operators options to *migrate* 
to DNSSEC rather than making forklift changes in their networks.

I'd simply like to see the option of doing RA, or not, or DHCP with 
option.routers, etc.

>> People who don't like this should blame their younger selves who failed to 
>> show up at the IETF ten years ago to get this done while DHCPv6 was still 
>> clean slate.
>> 
> 
> There were a lot of people who tried to "show up" at the IETF 10 years ago 
> and talk
> about this stuff from an operational perspective. They were basically told 
> that operators
> don't know what they want and they should shut up and go away and let real men
> do the work.

Indeed, again. I stopped going to IETF (for good or ill) in 1997 or so, but 
still following the mailing lists. I haven't been since, but sounds like this 
is still the status quo.

-b

Re: The stupidity of trying to "fix" DHCPv6

[Ricky Beam]

On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum  
 wrote:

BTW, does this broken software run over IPv6, anyway?


Poorly designed network plus poorly designed software... I don't know  
which chicken came first, and it doesn't matter.


IPv6 is totally different barnyard.  Build the v6 network properly -- one  
gateway (one router, vrrp, whatever) -- and retool the software properly.   
IPv6 doesn't have a broadcast address; as such if the software is setup to  
use an appropriate multicast target (presumably in "user defined" space),  
then it'll talk to exactly the right machines, and it's routable.


--Ricky

Re: The stupidity of trying to "fix" DHCPv6

[Ricky Beam]

On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong  wrote:
The point of /64 is to support automatic configuration and incredibly  
sparse host addressing.

It is not intended to create stupidly large broadcast domains.


Several IETF (and NANOG) discussions say otherwise.  While current  
hardware doesn't handle thousands of hosts, the protocol was designed for  
a future where that's not true. (there's a future where *everything* is  
network enabled... microwave oven, doorbell, weed whacker, everything.)


A /22 is probably about the upper limit of a sane broadcast domain, but,  
even with a /22
or 1022 nodes max, each sending a packet every 10 seconds you don't get  
to 100s of PPS,

you get 102.2pps.


As I said, DHCP isn't the only source of traffic.  Setup a 1000 node  
network today (just IPv4), and you will see a great deal of broadcast  
traffic (unless those nodes aren't doing anything.)  With IPv6, it's all  
multicast (v6 doesn't have a "broadcast address") hinged on switches  
filtering the traffic away from where it doesn't need to be.  The  
all-too-common Best Buy $20 white box ethernet switch does no multicast  
filtering at all.  Pretty much all wireless hardware sucks at multicast -  
period.  These are not things that can be fixed with a simple software  
update... if the silicon doesn't do it, *it doesn't do it*.

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

On Jun 14, 2011, at 2:42 PM, Seth Mos wrote:

> 
> Op 14 jun 2011, om 19:04 heeft Ray Soucy het volgende geschreven:
> 
>> My guess is within the next year we'll see something pop up that does this.
> 
> Ehm, It's already here, you searched google right?
> 
> I finished it 4 months ago. And a number of commercial platforms already 
> support it. Although Owen doesn't like it much.
> 
> I really wish there was a more bomb proof "lite" version of the BGP protocol.
> - One that has proper authentication not based on a single MD5.
> - One that does not allow the client side to define the networks.
> - That will only support default routes, it's easier if it can not carry the 
> world.
> 
Bullet 1: You're in luck... In IPv6, you can run BGP/IPSEC.
Works today.

Bullet 2: Not sure how you'd do that, but, since the "client side" can't control
what the upstream side accepts, I'm not sure why that matters.

Bullet 3: You have the option of doing that in BGP today, but, I don't know of
any versions of BGP that are so limited other than by memory constraints.

> I think a evolved version of ebgp multihop is workable, but you'd still need 
> some lightweight form of hooking back into the BGP table.
> 
Not sure what you mean by this.

Pretty simple, really... ISP advertises default and accepts  prefixes 
with a simple
prefix filter.

 accepts default and advertises own prefixes.

Done. Works today. Can mostly be fire-and-forget, even.

> Ideally, ISPs could deploy a number of these route "guides" that would inject 
> the proper route into the real BGP table, but by then it is filtered and the 
> ISP has proper control over what ends up in it. Some ISPs could mark this up 
> as a luxury version.
> 

Why not just do it as part of the customer interface configuration on the edge 
router? Why add the
complication of an extra box somewhere else to manage?

> Perhaps a form of PI bound to country (Exchange) would be a workable 
> solution. So request a piece of "country PI" that is delegated explicitly to 
> the roaming guide(s).
> 

Country PI is fail for a number of reasons.

Owen

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

On Jun 14, 2011, at 2:57 PM, Scott Helms wrote:

> 
>> Yes... The key word there is perception. The question is whether it makes
>> more sense to put effort into correcting mis-perceptions or to put the effort
>> into providing workarounds which provide a sub-par networking experience
>> to the end user.
>> 
>> IMNSHO, it is better to put effort into education. I'm surprised to find 
>> someone
>> from a .EDU on the opposite side of that thought. One would normally expect
>> them to favor the idea of education over hackery.
>> 
> 
> There are few things harder on the planet than changing perception and one of 
> the few is changing human behavior.   NAT is normal for many/most enterprises 
> and the thought of trying to explain sub-par networking to most business 
> leaders makes my teeth hurt.
> 

It only took us about 15 years to change behavior to NAT by default, so, I'm 
betting
that if we do the right thing and put in the effort, in 15 years, we can have a 
nice
NAT-free network. Personally, I think it's worth it.

I have very little trouble explaining sub-par networking to most of them. 
Usually
it goes something like this...

Remember when your IT department came to you with projections of enormous
savings on telephone costs in 2003 and your company did their first foray into
VOIP?

Yeah, that's a good example of sub-par networking.


Owen

Re: The stupidity of trying to "fix" DHCPv6

[Iljitsch van Beijnum]

On 15 jun 2011, at 0:05, Owen DeLong wrote:

> Yes, the right solution would be to at least separate the VLANs and clean up 
> this
> mess. However, due to software packages that need to talk to each other over
> common local broadcast across that boundary, this isn't possible in this 
> particular
> organization (don't get me started on the bad software, but, that's what 
> there is.)

Strange that you don't apply the logic of "the existing software is what there 
is" to the code deep inside hundreds of millions of hosts, but rather to 
obscure stuff that presumably hardly anyone uses.

If changing this software is so hard, what these people need is some filtering 
switches so the application multicasts get forwarded but the IP provisioning 
multicasts don't. No standards action required.

BTW, does this broken software run over IPv6, anyway?

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 1:30 PM, Ricky Beam wrote:

> On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong  wrote:
>> You would need an AWFUL lot of hosts for this to add up to a few 100pps (or 
>> even 10pps) of multicast traffic.
> 
> You're missing the point... most WAPs are horrible with multicast.  It 
> doesn't matter if it's v4 or v6, at L2, multicast is multicast.
> 
> At 100pps the WAP disappears from the network. "It's dead, Jim!"  In many 
> cases, a single multicast packet is enough to disrupt traffic flow as the AP 
> stops to fire the multicast frame, individually, at each associated peer.
> 
> As others have pointed out, IPv6 uses multicast all over the place.  DHCPv6 
> is just one of many sources.
> 
> All we're saying is DHCPv6 should be like DHCPv4... have a backoff period and 
> eventually give up entirely. (yes, there are v4 agents that continue to try, 
> i.e. restart every 5min, etc.)

Dude... I said that from the beginning.

Point is that DHCPv6 isn't going to be the thing that pushes your AP over the 
edge.

Owen

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 1:15 PM, Ricky Beam wrote:

> On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong  wrote:
>> That was kind of my point. You are unlikely to encounter such a large L2 
>> domain outside of an exchange point.
> 
> I've seen such large networks in private industry (and governements, not just 
> the US) several times.  And IPv6 has been designed (poorly, it would now 
> appear) for huge "LAN"s -- LANs are supposed to be /64, after all.
> 
> One of them "had" to have such stupid large L2 domains because they used RIP 
> (v1) EVERYWHERE. (all networks had to be /22's)  They made a god aweful mess 
> trying to switch to OSPF, got fined by a three letter regulatory agency, and 
> are probably still running RIPv1 to this day.

The point of /64 is to support automatic configuration and incredibly sparse 
host addressing.
It is not intended to create stupidly large broadcast domains.

A /22 is probably about the upper limit of a sane broadcast domain, but, even 
with a /22
or 1022 nodes max, each sending a packet every 10 seconds you don't get to 100s 
of PPS,
you get 102.2pps.

Owen

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 11:00 AM, Ben Jencks wrote:

> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
> 
>> Then use RA and move on. However, please understand that yours
>> is not the only environment and that there are real-world scenarios
>> where having the router-guys dictate the host configuration is considered
>> unacceptable at best.
> 
> This has always confused me. What aspect of host configuration is the router 
> providing that's so problematic? The prefix, which has to match on the router 
> and host in order for anything to work anyway? The indication to go use 
> DHCPv6, which doesn't really add anything since you need to configure a 
> DHCPv6 proxy anyway? There's just so little information in an RA, and the 
> router needs to know it all anyway, that I'm having trouble understanding 
> what environment would find this so horrifying.
> 
> -Ben

Imagine this scenario...


[RA][RB][RC] [RD]
  |   |   ||
[-+---+---+---+---++---+---+---+---+---+---+---+---+---+-]
  |   ||   |   |   |   |   |   |   |   |
[AR] [AP]   [ACCTG]   [D1] |  [D2] |  [D3] |  [W1] [W2]
  [L1][R1]

AR is Accts Receivable
AP is Accts Payable
ACCTG is the Accts server
D1-D3 are developer workstations.
W1-W2 are internal application web servers
L1 is the lobby computer (badging kiosk)
R1 is the Receptionist.

RA, RB are routers which are run by IT and connect off to the
IT subnets in the main building.

RC, RD are routers which are run by the DEV group and connect
off to the DEV group subnets in the main building.




See... This is an oversimplification, but, these things happen in the real 
world.
The desire is for the AR/AP/ACCTG/L1/R1 hosts to use the RA/RB prefixes
and default gateways. Currently that's done by the DHCP server knowing which
MAC addresses to expect for those systems. Everything else gets shunted to
the DEV network.

Yes, the right solution would be to at least separate the VLANs and clean up 
this
mess. However, due to software packages that need to talk to each other over
common local broadcast across that boundary, this isn't possible in this 
particular
organization (don't get me started on the bad software, but, that's what there 
is.)

There are large varieties of other situations where having the router supply
prefix and default gateway information on the theory that all routers on a
link are created equal and anyone on a link may use any router (priority
doesn't help here because the goal is to have different hosts use different
sets of gateways).

Which prefix does "the prefix" have to match? How, using RA, do you assign
the RC/RD prefix(es) to the D1-D3 hosts and the RA/RB prefix(es) to everything
else (or vice versa)?

Sometimes link != subnet.

Owen

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 11:14 AM, Ray Soucy wrote:

>> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
>> What is needed is:
>> 
>>   -   Native RA Guard in switches
>>   -   Native DHCPv6 Snooping in switches
>>   -   Native RA Guard in WAPs
>>   -   Native DHCPv6 Snooping in WAPs
>>   -   Additional options to DHCPv6 for Routing Information
>>   -   Eventual changes to host DHCPv6 Client behavior so that
>>   DHCP does occur when RA not present.
> 
> Agree 100%
> 
> Especially with the last one; DHCPv6 clients shouldn't even be started
> unless they see the M flag set; but that's an implementation
> challenge.

That's the current broken behavior. The goal is to correct that problem.

> 
> Would probably include something analogous to ARP inspection for
> neighbor discovery; and that router implementations are modified so
> that once full, the neighbor table won't throw out known associations
> in favor of unknown associations to mitigate the denial of service
> attack vector present when using 64-bit prefixes.  Perhaps DAD
> flooding protection too.  It's a "new" protocol, so it will take a
> while for all these things to be worked out and become standard.
> 

That would also likely be good, but, I don't think that requires IETF effort.

> On Tue, Jun 14, 2011 at 2:00 PM, Ben Jencks  wrote:
> 
>> This has always confused me. What aspect of host configuration is the router 
>> providing that's so
>> problematic? The prefix, which has to match on the router and host in order 
>> for anything to work
>> anyway? The indication to go use DHCPv6, which doesn't really add anything 
>> since you need to
>> configure a DHCPv6 proxy anyway? There's just so little information in an 
>> RA, and the router needs to
>> know it all anyway, that I'm having trouble understanding what environment 
>> would find this so
>> horrifying.
> 
> And This.
> 
> Really, people make way too big a deal about RA, and I think most of
> it comes from the lack of vendor support for filtering of rouge RA and
> the fact that Windows ICS happily sends them out.
> 

No, that is not the only place it comes from. There are real world networks
that don't have a good solution with RA because RA assumes that link==subnet
and that simply isn't true in all cases.

> I still blame vendors; this design has been known for a long time now
> and they still haven't come up to speed, in part because people spend
> their time complaining on NANOG instead of to their sales rep.
> 

Believe me, I've done both.

Owen

> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

On Jun 14, 2011, at 11:00 AM, Ray Soucy wrote:

> I think that's a market problem rather than a routing problem.  In the
> long term, If we had separation of L2 and L3 service providers there
> would be very, very few who need L3 redundancy; and that amount would
> be fine using BGP.
> 
ROFLMAO... You're joking, right? Oh, you're serious... OK... I encourage
my competitors to try that.

> Metro Ethernet services are making it a bit easier to accomplish this;
> but every ISP wants you to use them for everything so it's still a
> challenge.
> 

I would still want L3 redundancy and I can't imagine any of my clients
choosing to go with diverse L2 paths to the same L3 provider as a
valid complete solution for redundancy.

> I would really like to see L2 optical services being treated as a
> public utility; and you just purchase your L3 from any provider you
> want.  Prices would go down because we wouldn't be wasting money on
> building identical fiber paths, and bandwidth would go up.  Have a
> problem with your current ISP? The switch to a different one can be
> done with a phone call; you don't even need to have a technician sent
> out.
> 

Agreed, but, that doesn't change the fact that L3 redundancy is still
a requirement for a growing (not shrinking) number of organizations.
That's not a market issue, that _IS_ a routing issue.

The good news on that front, however, is that if we get from o(10+) prefixes
per organization to o(2) prefixes per organization, we get a dramatically
smaller routing table with iPv6 fully deployed and can accommodate a
pretty hefty number of additional organizations in IPv6.

> Maine recently started the ground work for that by making a new class
> of Public Utility for Dark Fiber, but it doesn't allow them to light
> it up.
> 
It's been done in Sweden and is being done in AU as well. I've been
advocating an independent monopoly LMI non-profit available to all
higher tier service providers on an equal basis for years. Glad to see
it's starting to finally catch on in a couple of places.

Owen

> On Tue, Jun 14, 2011 at 1:48 PM, Owen DeLong  wrote:
>> Actually, a vastly inferior solution, but, it does have the attraction of
>> being able to continue to ignore the need for scalable routing for several
>> more years.
>> 
>> In reality, we need to solve the scalable routing problem at some point
>> and having everyone jump into the IPv6 BGP world for multihoming
>> would be sustainable long enough for that problem to get solved if
>> resources were focused on it.
>> 
>> Owen
>> 
>> On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote:
>> 
>>> Today you're probably correct.  If you want to have more than one
>>> provider reliably you pretty much need to be doing BGP; or have some
>>> sort of primary-backup setup to fail over from one to the other; or
>>> give each host a global address from each provider (really not
>>> desirable in the majority of networks).
>>> 
>>> I think in the long term telling everyone to jump into the BGP table
>>> is not sustainable; and not operationally consistent with the majority
>>> of SMB networks.
>>> 
>>> A better solution; and the one I think that will be adopted in the
>>> long term as soon as vendors come into the fold, is to swap out
>>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>>> policy routing to handle load balancing and failover the way most
>>> "dual WAN" multifunction firewalls do today.
>>> 
>>> Example:
>>> 
>>> Each provider provides a 48-bit prefix;
>>> 
>>> Internally you use a ULA prefix; and setup prefix translation so that
>>> the prefix gets swapped appropriately for each uplink interface.  This
>>> provides the benefits of "NAT" used today; without the drawback of
>>> having to do funky port rewriting and restricting incoming traffic to
>>> mapped assignments or UPnP.
>>> 
>>> The firewall keeps track of if a connection is up or down and keeps
>>> policy routing up to date;
>>> 
>>> You can choose to set it up to either load balance per-flow or as a
>>> primary and backup interface.
>>> 
>>> You can handle DNS by using RFC 2136 updates for a sub-domain with a
>>> short TTL on a hosted server to keep names up to date in the event of
>>> a link drop.
>>> 
>>> This doesn't require cooperation from the provider; it doesn't require
>>> knowledge of routing protocols; and it is easy to understand for
>>> people used to the "NAT" environment.
>>> 
>>> Last time I checked, Linux still needs some work to handle ECMP
>>> routing for IPv6, but once that is in place; combined with patches for
>>> Network Prefix Translation (NPT), it should be trivial to implement.
>>> 
>>> My guess is within the next year we'll see something pop up that does this.
>>> 
>>> Ray
>>> 
>>> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong  wrote:
 The vastly better option is to obtain a prefix and ASN from ARIN and 
 merely trade BGP with your
 upstream providers.
 
 Prefix translation comes with all the same disabilities that are p

Re: Question about migrating to IPv6 with multiple upstreams.

[Scott Helms]

Yes... The key word there is perception. The question is whether it makes
more sense to put effort into correcting mis-perceptions or to put the effort
into providing workarounds which provide a sub-par networking experience
to the end user.

IMNSHO, it is better to put effort into education. I'm surprised to find someone
from a .EDU on the opposite side of that thought. One would normally expect
them to favor the idea of education over hackery.



There are few things harder on the planet than changing perception and 
one of the few is changing human behavior.   NAT is normal for many/most 
enterprises and the thought of trying to explain sub-par networking to 
most business leaders makes my teeth hurt.


Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

On Jun 14, 2011, at 10:52 AM, Ray Soucy wrote:

> It's a security and operational issue.
> 
> The perception is that it's easier to monitor, manage, and filter one
> address per host instead of 3.  For most in the enterprise world it's
> a non-starter to have that setup; even if that perception is a false
> one.
> 

Yes... The key word there is perception. The question is whether it makes
more sense to put effort into correcting mis-perceptions or to put the effort
into providing workarounds which provide a sub-par networking experience
to the end user.

IMNSHO, it is better to put effort into education. I'm surprised to find someone
from a .EDU on the opposite side of that thought. One would normally expect
them to favor the idea of education over hackery.

> Not sure I have the energy to re-hash the tired old NAT debate though. ;-)
> 

That sound you hear is me breathing a sigh of relief. I will continue to do
it as long as it remains necessary, but, I'm tired of it too.

Owen

> On Tue, Jun 14, 2011 at 1:38 PM,   wrote:
>> On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said:
>> 
>>> A better solution; and the one I think that will be adopted in the
>>> long term as soon as vendors come into the fold, is to swap out
>>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>>> policy routing to handle load balancing and failover the way most
>>> "dual WAN" multifunction firewalls do today.
>>> 
>>> Example:
>>> 
>>> Each provider provides a 48-bit prefix;
>>> 
>>> Internally you use a ULA prefix; and setup prefix translation so that
>>> the prefix gets swapped appropriately for each uplink interface.  This
>>> provides the benefits of "NAT" used today; without the drawback of
>>> having to do funky port rewriting and restricting incoming traffic to
>>> mapped assignments or UPnP.
>> 
>> Why do people insist on creating solutions where each host has exactly one 
>> IPv6
>> address, instead of letting each host have *three* (in this case) - a ULA and
>> two provider-prefixed addresses?
>> 
> 
> 
> 
> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/

Re: AUS?

[Jay Ashworth]

- Original Message -
> From: "Jay Ashworth" 

> http://www.outages.org/index.php/Network_ops_group_websites

And silly me, I didn't *check the link* before posting that.  Fixed now.
Sorry for the noise.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Question about migrating to IPv6 with multiple upstreams.

[Seth Mos]

Op 14 jun 2011, om 19:04 heeft Ray Soucy het volgende geschreven:

> My guess is within the next year we'll see something pop up that does this.

Ehm, It's already here, you searched google right?

I finished it 4 months ago. And a number of commercial platforms already 
support it. Although Owen doesn't like it much.

I really wish there was a more bomb proof "lite" version of the BGP protocol.
- One that has proper authentication not based on a single MD5.
- One that does not allow the client side to define the networks.
- That will only support default routes, it's easier if it can not carry the 
world.

I think a evolved version of ebgp multihop is workable, but you'd still need 
some lightweight form of hooking back into the BGP table.

Ideally, ISPs could deploy a number of these route "guides" that would inject 
the proper route into the real BGP table, but by then it is filtered and the 
ISP has proper control over what ends up in it. Some ISPs could mark this up as 
a luxury version.

Perhaps a form of PI bound to country (Exchange) would be a workable solution. 
So request a piece of "country PI" that is delegated explicitly to the roaming 
guide(s).

Regards,

Seth

Re: The stupidity of trying to "fix" DHCPv6

[Leo Bicknell]

In a message written on Tue, Jun 14, 2011 at 05:01:24PM -0400, Ben Jencks wrote:
> > Lastly, there's a hidden bit here many people haven't dealt with
> > yet in lab networks.  In IPv4 critical environments it's typical
> > to use HSRP or VRRP to provide a single gateway across two routers.
> > The IPv6 way to do this is to have both advertise RA's, possibly
> > with different priorities.
> 
> Erm, I thought the IPv6 way to do it was to use IPv6 VRRP... I've heard of 
> some vendor bugs on it, but it's implemented.

You can do VRRPv6 (now, finally, on some platforms).  However, the
standard way this works is, wait for it, advertising the default
gateway via RA's!

At least you can static route to the VRRPv6 address and that works
without RA's.  Again, it would be nice to give out the address in
DHCPv6 and not need RA's at all, but alas there is no default route
field in DHCPv6.

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


pgpmrTRpQ7Fij.pgp
Description: PGP signature

Routing study - take 2

[Vytautas Valancius]

Hi NANOG,

>From June 20th to July 20th Georgia Tech will conduct an Internet
routing study using AS-PATH poisoning. We will insert AS numbers into
one of our announcements to route around some networks.

The study will *only* affect the the Georgia Tech prefix
184.164.224.0/21. The prefix serves *no active users* for the duration
of study. We will always start AS-PATH with our own AS 47065. We will
limit ourselves to 10 announcement changes per hour.

Similar studies were done before (e.g. by Randy Bush et al.:
http://www.psg.com/~olaf/measurements/as3130/visibility.pdf). If, for
any reason, you want us not to taint our prefix with you AS number,
please opt-out at any time at: http://www.surveymonkey.com/s/WGLV6QR

Regards,
Vytautas Valancius
http://valas.gtnoise.net/
Georgia Tech

Re: The stupidity of trying to "fix" DHCPv6

[Ben Jencks]

On Jun 14, 2011, at 4:25 PM, Leo Bicknell wrote:

> In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks 
> wrote:
>> This has always confused me. What aspect of host configuration is the router 
>> providing that's so problematic? The prefix, which has to match on the 
>> router and host in order for anything to work anyway? The indication to go 
>> use DHCPv6, which doesn't really add anything since you need to configure a 
>> DHCPv6 proxy anyway? There's just so little information in an RA, and the 
>> router needs to know it all anyway, that I'm having trouble understanding 
>> what environment would find this so horrifying.

> [snipped long explanation that you do in fact need DNS servers]
> 
> So just like in IPv4, IPv6 requires DHCP to have a functioning end user
> box.  DHCP remains a hard requirement.  The odd part now is that in IPv4
> DHCP carries the default gateway, while in IPv6 land you must also run
> Router Advertisements on your router and have the host listen to them.
> 
> The industry has taken a robust single protocol solution and turned it
> into a dual, co-dependent protocol situation.

I'm just not seeing how this actually adds more configuration overhead. Rather 
than looking at a protocol count, try looking at the number of actual items you 
need to configure and where they get configured. This is actually *smaller* in 
IPv6, because the DHCPv6 server doesn't need to know what the default gateways 
are anymore (I have no problem with a routing information option, but that's 
optional, not *needed*). The fact that the information is distributed over 
different protocols seems to make a lot of people really pissed off, but seems 
ancillary to the actual issues of what information is configured where and what 
options are available.

> 
> The IETF is working on one solution, which is to add DNS information to
> the RA's!  So now you'll configure your routers to hand out DNS servers
> to clients, and then everything else (NTP servers, Domain Controllers,
> etc) in DHCP!

I agree, that's never seemed like a good idea.

> What I and others are suggesting is the other way around, how about we
> just put a default route in DHCPv6 like we did in v4, and forget all
> about RA's so we're back to a single protocol solution?
> 
> Beyond that it is important to notice that the failure modes and attack
> vectors for RA's and DHCP are different.  I argue DHCP is "better", but
> I also realize that's a very subjective judgment.  That said, there
> are cases where people may prefer DHCP's robustness and/or failure
> modes, and cases where people might prefer RA's.

There are differences in failure modes, but I'd argue that's not enough 
justification to fragment the configuration options. If there are two 
overlapping ways to configure things, then I'd bet that all but the most 
mainstream or high-end implementations will have poor support for at least one. 
That was the one you chose? Too bad, you have to support both now. So much for 
the "operator choice" you keep arguing for.

> Lastly, there's a hidden bit here many people haven't dealt with
> yet in lab networks.  In IPv4 critical environments it's typical
> to use HSRP or VRRP to provide a single gateway across two routers.
> The IPv6 way to do this is to have both advertise RA's, possibly
> with different priorities.

Erm, I thought the IPv6 way to do it was to use IPv6 VRRP... I've heard of some 
vendor bugs on it, but it's implemented.

Multiple routers sending RAs can be useful, but not for the same kind of HA 
that VRRP is designed for.

-Ben

Re: The stupidity of trying to "fix" DHCPv6

[Matt Addison]

On Tue, Jun 14, 2011 at 12:41, Ray Soucy  wrote:
>
> The energy in this thread should be focused on switch vendors to
> actually implement L2 security features for IPv6, which is usually an
> easy upgrade; rather than calling for all host implementations of IPv6
> to work differently; which will take a decade to implement and be a
> band-aid at best; not a good long-term design for the protocol.

There was a thread on this subject over on ipv6-ops (Hello to the list
and RA guard evasion technique) recently which outlined some of the
problems currently facing vendors and implementing those 'easy
upgrade' L2 security features. Due to the current state of host stacks
with regards to fragment reassembly it's almost impossible to
implement easily on a layer 2 device without exposing yourself to
other DoS possibilities.

There're also some I-Ds which cover the issues:
http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt
http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt

~Matt

Re: The stupidity of trying to "fix" DHCPv6

[Ricky Beam]

On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong  wrote:
You would need an AWFUL lot of hosts for this to add up to a few 100pps  
(or even 10pps) of multicast traffic.


You're missing the point... most WAPs are horrible with multicast.  It  
doesn't matter if it's v4 or v6, at L2, multicast is multicast.


At 100pps the WAP disappears from the network. "It's dead, Jim!"  In many  
cases, a single multicast packet is enough to disrupt traffic flow as the  
AP stops to fire the multicast frame, individually, at each associated  
peer.


As others have pointed out, IPv6 uses multicast all over the place.   
DHCPv6 is just one of many sources.


All we're saying is DHCPv6 should be like DHCPv4... have a backoff period  
and eventually give up entirely. (yes, there are v4 agents that continue  
to try, i.e. restart every 5min, etc.)

Re: The stupidity of trying to "fix" DHCPv6

[Leo Bicknell]

In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote:
> This has always confused me. What aspect of host configuration is the router 
> providing that's so problematic? The prefix, which has to match on the router 
> and host in order for anything to work anyway? The indication to go use 
> DHCPv6, which doesn't really add anything since you need to configure a 
> DHCPv6 proxy anyway? There's just so little information in an RA, and the 
> router needs to know it all anyway, that I'm having trouble understanding 
> what environment would find this so horrifying.

The problem for most folks is that it becomes an "in addition to"
thing to support, troubleshoot, and debug.  To make that ok, you
have to look at the cost/benefits.

I urge everyone in this thread to try a simple experiment.  Configure
an IPv6 segment in your lab.  Make sure there is no IPv4 on it, not
on the router, and that the IPv4 stack (to the extent possible) is
disabled on the hosts.  Now try to use one of the hosts to access IPv6
content.

You'll find the box does SLAAC just fine and gets an address.  You'll
find RA's provide a default gateway and can get your packets out to the
world.  You'll also find absolutely nothing works, at a bare minimum
because you have no DNS servers.

People aren't noticing this today because they are dual stack, and end
up reaching their DNS servers from IPv4 DHCP information over IPv4
transport.  They may then get 's, and use IPv6 after that.

Your box is dead in the water.  How do you get DNS servers?  Today
the answer is to run DHCPv6.  Of course if you need other options
(netboot information, NTP servers, domain controllers, and so on) you
also need DHCPv6 to get a functioning box.

So just like in IPv4, IPv6 requires DHCP to have a functioning end user
box.  DHCP remains a hard requirement.  The odd part now is that in IPv4
DHCP carries the default gateway, while in IPv6 land you must also run
Router Advertisements on your router and have the host listen to them.

The industry has taken a robust single protocol solution and turned it
into a dual, co-dependent protocol situation.

The IETF is working on one solution, which is to add DNS information to
the RA's!  So now you'll configure your routers to hand out DNS servers
to clients, and then everything else (NTP servers, Domain Controllers,
etc) in DHCP!

What I and others are suggesting is the other way around, how about we
just put a default route in DHCPv6 like we did in v4, and forget all
about RA's so we're back to a single protocol solution?

Beyond that it is important to notice that the failure modes and attack
vectors for RA's and DHCP are different.  I argue DHCP is "better", but
I also realize that's a very subjective judgment.  That said, there
are cases where people may prefer DHCP's robustness and/or failure
modes, and cases where people might prefer RA's.

Lastly, there's a hidden bit here many people haven't dealt with
yet in lab networks.  In IPv4 critical environments it's typical
to use HSRP or VRRP to provide a single gateway across two routers.
The IPv6 way to do this is to have both advertise RA's, possibly
with different priorities.  Depending on your environment this may
or may not be as "feature rich" for you.  For instance RA's timers
aren't as adjustable (as they depend on end hosts), and I don't
know of any vendor who implements interface tracking for RA's the
way it is done with HSRP/VRRP.

We need more folks using IPv6 in production to find this stuff.  If you
spin up a dual stacked box in the lab with a single router RA's work
great, DHCPv4 gives you DNS, and you'll never notice any issues.  Run a
dual-router IPv6 only production network for some end users, and you'll
notice some differences, and I think find that some of those differences
are deficiencies.

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


pgp1frxQAdR53.pgp
Description: PGP signature

Re: The stupidity of trying to "fix" DHCPv6

[Ricky Beam]

On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong  wrote:
That was kind of my point. You are unlikely to encounter such a large L2  
domain outside of an exchange point.


I've seen such large networks in private industry (and governements, not  
just the US) several times.  And IPv6 has been designed (poorly, it would  
now appear) for huge "LAN"s -- LANs are supposed to be /64, after all.


One of them "had" to have such stupid large L2 domains because they used  
RIP (v1) EVERYWHERE. (all networks had to be /22's)  They made a god  
aweful mess trying to switch to OSPF, got fined by a three letter  
regulatory agency, and are probably still running RIPv1 to this day.

Re: Question about migrating to IPv6 with multiple upstreams.

[Joel Jaeggli]

On Jun 14, 2011, at 10:38 AM, valdis.kletni...@vt.edu wrote:

> On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said:
> 
>> A better solution; and the one I think that will be adopted in the
>> long term as soon as vendors come into the fold, is to swap out
>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>> policy routing to handle load balancing and failover the way most
>> "dual WAN" multifunction firewalls do today.
>> 
>> Example:
>> 
>> Each provider provides a 48-bit prefix;
>> 
>> Internally you use a ULA prefix; and setup prefix translation so that
>> the prefix gets swapped appropriately for each uplink interface.  This
>> provides the benefits of "NAT" used today; without the drawback of
>> having to do funky port rewriting and restricting incoming traffic to
>> mapped assignments or UPnP.
> 
> Why do people insist on creating solutions where each host has exactly one 
> IPv6
> address, instead of letting each host have *three* (in this case) - a ULA and
> two provider-prefixed addresses?

and a link-local

Re: IPv6 - a noobs prespective

[James Harr]

Really -- just go play with it. I started by setting up a
tunnelbroker.net account at home.

A majority of the packet slapping functionality of routers work just
fine. It's when you get into things like applications, load balancing,
NAT64/DNS64 where things start to get a little buggy. And you'll never
get to those things unless there's some basic IPv6 on your network
already.

At work, we started by deploying it across the routers, but not to any
end hosts. This way we can turn IPv6 on/off to specific end-host VLANs
without much effort. Currently, our techs and one enthusiastic end
user group have IPv6 and it seems to be running well. After the
basics, it's going through one application/service at a time and
getting it on IPv6.

On Tue, Jun 14, 2011 at 11:44 AM, Octavio Alvarez
 wrote:
>
> On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby  wrote:
>
>> I am however *terrified* of making that move. There is so many new phrases, 
>> words, things to think about etc
>
> You fears will significantly lower after you set up a separate lab and
> play with it. With something as simple as a switch you can make a simple
> IPv6-only network. Try to replicate your current network in the lab as
> far as you can, using the "new" concepts and techniques and understand
> the current state of the art (read that as RA+DHCPv6, etc.) Get your
> pings right.
>
> This will automatically get you to dual-stacking, as in "how do I make
> both protocols work in the same physical network?". They just do. At
> this point the problem stops belonging to the network infrastructure
> and it passes on to the application servers and hosts.
>
> (And ask your ISP to support IPv6).
>
> Good luck.
>
> --
> Octavio.
>



--
^[:wq^M

Re: The stupidity of trying to "fix" DHCPv6

[Ray Soucy]

> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
> What is needed is:
>
>-   Native RA Guard in switches
>-   Native DHCPv6 Snooping in switches
>-   Native RA Guard in WAPs
>-   Native DHCPv6 Snooping in WAPs
>-   Additional options to DHCPv6 for Routing Information
>-   Eventual changes to host DHCPv6 Client behavior so that
>DHCP does occur when RA not present.

Agree 100%

Especially with the last one; DHCPv6 clients shouldn't even be started
unless they see the M flag set; but that's an implementation
challenge.

Would probably include something analogous to ARP inspection for
neighbor discovery; and that router implementations are modified so
that once full, the neighbor table won't throw out known associations
in favor of unknown associations to mitigate the denial of service
attack vector present when using 64-bit prefixes.  Perhaps DAD
flooding protection too.  It's a "new" protocol, so it will take a
while for all these things to be worked out and become standard.

On Tue, Jun 14, 2011 at 2:00 PM, Ben Jencks  wrote:

> This has always confused me. What aspect of host configuration is the router 
> providing that's so
> problematic? The prefix, which has to match on the router and host in order 
> for anything to work
> anyway? The indication to go use DHCPv6, which doesn't really add anything 
> since you need to
> configure a DHCPv6 proxy anyway? There's just so little information in an RA, 
> and the router needs to
> know it all anyway, that I'm having trouble understanding what environment 
> would find this so
> horrifying.

And This.

Really, people make way too big a deal about RA, and I think most of
it comes from the lack of vendor support for filtering of rouge RA and
the fact that Windows ICS happily sends them out.

I still blame vendors; this design has been known for a long time now
and they still haven't come up to speed, in part because people spend
their time complaining on NANOG instead of to their sales rep.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

Re: The stupidity of trying to "fix" DHCPv6

[Ben Jencks]

On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:

> Then use RA and move on. However, please understand that yours
> is not the only environment and that there are real-world scenarios
> where having the router-guys dictate the host configuration is considered
> unacceptable at best.

This has always confused me. What aspect of host configuration is the router 
providing that's so problematic? The prefix, which has to match on the router 
and host in order for anything to work anyway? The indication to go use DHCPv6, 
which doesn't really add anything since you need to configure a DHCPv6 proxy 
anyway? There's just so little information in an RA, and the router needs to 
know it all anyway, that I'm having trouble understanding what environment 
would find this so horrifying.

-Ben

Re: Question about migrating to IPv6 with multiple upstreams.

[Ray Soucy]

I think that's a market problem rather than a routing problem.  In the
long term, If we had separation of L2 and L3 service providers there
would be very, very few who need L3 redundancy; and that amount would
be fine using BGP.

Metro Ethernet services are making it a bit easier to accomplish this;
but every ISP wants you to use them for everything so it's still a
challenge.

I would really like to see L2 optical services being treated as a
public utility; and you just purchase your L3 from any provider you
want.  Prices would go down because we wouldn't be wasting money on
building identical fiber paths, and bandwidth would go up.  Have a
problem with your current ISP? The switch to a different one can be
done with a phone call; you don't even need to have a technician sent
out.

Maine recently started the ground work for that by making a new class
of Public Utility for Dark Fiber, but it doesn't allow them to light
it up.

On Tue, Jun 14, 2011 at 1:48 PM, Owen DeLong  wrote:
> Actually, a vastly inferior solution, but, it does have the attraction of
> being able to continue to ignore the need for scalable routing for several
> more years.
>
> In reality, we need to solve the scalable routing problem at some point
> and having everyone jump into the IPv6 BGP world for multihoming
> would be sustainable long enough for that problem to get solved if
> resources were focused on it.
>
> Owen
>
> On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote:
>
>> Today you're probably correct.  If you want to have more than one
>> provider reliably you pretty much need to be doing BGP; or have some
>> sort of primary-backup setup to fail over from one to the other; or
>> give each host a global address from each provider (really not
>> desirable in the majority of networks).
>>
>> I think in the long term telling everyone to jump into the BGP table
>> is not sustainable; and not operationally consistent with the majority
>> of SMB networks.
>>
>> A better solution; and the one I think that will be adopted in the
>> long term as soon as vendors come into the fold, is to swap out
>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>> policy routing to handle load balancing and failover the way most
>> "dual WAN" multifunction firewalls do today.
>>
>> Example:
>>
>> Each provider provides a 48-bit prefix;
>>
>> Internally you use a ULA prefix; and setup prefix translation so that
>> the prefix gets swapped appropriately for each uplink interface.  This
>> provides the benefits of "NAT" used today; without the drawback of
>> having to do funky port rewriting and restricting incoming traffic to
>> mapped assignments or UPnP.
>>
>> The firewall keeps track of if a connection is up or down and keeps
>> policy routing up to date;
>>
>> You can choose to set it up to either load balance per-flow or as a
>> primary and backup interface.
>>
>> You can handle DNS by using RFC 2136 updates for a sub-domain with a
>> short TTL on a hosted server to keep names up to date in the event of
>> a link drop.
>>
>> This doesn't require cooperation from the provider; it doesn't require
>> knowledge of routing protocols; and it is easy to understand for
>> people used to the "NAT" environment.
>>
>> Last time I checked, Linux still needs some work to handle ECMP
>> routing for IPv6, but once that is in place; combined with patches for
>> Network Prefix Translation (NPT), it should be trivial to implement.
>>
>> My guess is within the next year we'll see something pop up that does this.
>>
>> Ray
>>
>> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong  wrote:
>>> The vastly better option is to obtain a prefix and ASN from ARIN and merely 
>>> trade BGP with your
>>> upstream providers.
>>>
>>> Prefix translation comes with all the same disabilities that are present 
>>> when you do this in IPv4.
>>>
>>> In IPv4, everyone's software expects you to have a broken network (NAT) and 
>>> there is lots of extra
>>> code in all of the applications to work around this.
>>>
>>> In iPv6, it is not unlikely that this code will eventually get removed and 
>>> you will then have a high
>>> level of application problems in your "prefix-translated" environment.
>>>
>>> Owen
>>>
>>> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote:
>>>
 Prefix translation looks to be exactly what we need to do here. Thanks for 
 all of the replies.


 -Randy

 On Jun 12, 2011, at 2:42, Seth Mos  wrote:

>
> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven:
>
>>
>> I have an interesting situation at a business that I am working on. We 
>> currently have the office set up with redundant connections for their 
>> mission critical servers and such, and also have a (cheap) cable modem 
>> for general browsing on client machines.
>
> So basically policy routing?
>
>> The interesting part is that the client machines need to access some 
>> customer networks via the main

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

On Jun 14, 2011, at 10:28 AM, William Herrin wrote:

> On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy  wrote:
>> I think in the long term telling everyone to jump into the BGP table
>> is not sustainable; and not operationally consistent with the majority
>> of SMB networks.
>> 
>> A better solution; and the one I think that will be adopted in the
>> long term as soon as vendors come into the fold, is to swap out
>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>> policy routing to handle load balancing and failover the way most
>> "dual WAN" multifunction firewalls do today.
>> 
>> Example:
>> 
>> Each provider provides a 48-bit prefix;
>> 
>> Internally you use a ULA prefix; and setup prefix translation so that
>> the prefix gets swapped appropriately for each uplink interface.  This
>> provides the benefits of "NAT" used today; without the drawback of
>> having to do funky port rewriting and restricting incoming traffic to
>> mapped assignments or UPnP.
> 
> Hi Ray,
> 
> There's a nuance here you've missed.
> 
> There are two main reasons for ULA inside the network:
> 
> 1. Address stability (simplifies network management)
> 2. Source obfuscation (improves the depth of the security plan)
> 
> Option 1: Obfuscation desired.
> 
> ULA inside. NAT/PAT at both borders. You don't use prefix translation
> here because prefix translation does little obfuscation: it has a 1:1
> relationship with each individual host and still reveals the internal
> routing structure.
> 
> Option 2: Stability, no obfuscation desired.
> 
> ULA inside, prefix translation at both borders.
> 
> Option 3: Neither stability nor obfuscation required.
> 
> GUA from one of the providers inside. Prefix translation to the other
> provider for the connections desired out that border. Giving the hosts
> real GUA addresses maximizes application compatibility.
> 

If you're going to go with option 3, why not just put both GUA on the
hosts and set up proper rules for source address selection to control
the outbound preferences?

Owen

Re: Question about migrating to IPv6 with multiple upstreams.

[Ray Soucy]

It's a security and operational issue.

The perception is that it's easier to monitor, manage, and filter one
address per host instead of 3.  For most in the enterprise world it's
a non-starter to have that setup; even if that perception is a false
one.

Not sure I have the energy to re-hash the tired old NAT debate though. ;-)

On Tue, Jun 14, 2011 at 1:38 PM,   wrote:
> On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said:
>
>> A better solution; and the one I think that will be adopted in the
>> long term as soon as vendors come into the fold, is to swap out
>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>> policy routing to handle load balancing and failover the way most
>> "dual WAN" multifunction firewalls do today.
>>
>> Example:
>>
>> Each provider provides a 48-bit prefix;
>>
>> Internally you use a ULA prefix; and setup prefix translation so that
>> the prefix gets swapped appropriately for each uplink interface.  This
>> provides the benefits of "NAT" used today; without the drawback of
>> having to do funky port rewriting and restricting incoming traffic to
>> mapped assignments or UPnP.
>
> Why do people insist on creating solutions where each host has exactly one 
> IPv6
> address, instead of letting each host have *three* (in this case) - a ULA and
> two provider-prefixed addresses?
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

Actually, a vastly inferior solution, but, it does have the attraction of
being able to continue to ignore the need for scalable routing for several
more years.

In reality, we need to solve the scalable routing problem at some point
and having everyone jump into the IPv6 BGP world for multihoming
would be sustainable long enough for that problem to get solved if
resources were focused on it.

Owen

On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote:

> Today you're probably correct.  If you want to have more than one
> provider reliably you pretty much need to be doing BGP; or have some
> sort of primary-backup setup to fail over from one to the other; or
> give each host a global address from each provider (really not
> desirable in the majority of networks).
> 
> I think in the long term telling everyone to jump into the BGP table
> is not sustainable; and not operationally consistent with the majority
> of SMB networks.
> 
> A better solution; and the one I think that will be adopted in the
> long term as soon as vendors come into the fold, is to swap out
> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
> policy routing to handle load balancing and failover the way most
> "dual WAN" multifunction firewalls do today.
> 
> Example:
> 
> Each provider provides a 48-bit prefix;
> 
> Internally you use a ULA prefix; and setup prefix translation so that
> the prefix gets swapped appropriately for each uplink interface.  This
> provides the benefits of "NAT" used today; without the drawback of
> having to do funky port rewriting and restricting incoming traffic to
> mapped assignments or UPnP.
> 
> The firewall keeps track of if a connection is up or down and keeps
> policy routing up to date;
> 
> You can choose to set it up to either load balance per-flow or as a
> primary and backup interface.
> 
> You can handle DNS by using RFC 2136 updates for a sub-domain with a
> short TTL on a hosted server to keep names up to date in the event of
> a link drop.
> 
> This doesn't require cooperation from the provider; it doesn't require
> knowledge of routing protocols; and it is easy to understand for
> people used to the "NAT" environment.
> 
> Last time I checked, Linux still needs some work to handle ECMP
> routing for IPv6, but once that is in place; combined with patches for
> Network Prefix Translation (NPT), it should be trivial to implement.
> 
> My guess is within the next year we'll see something pop up that does this.
> 
> Ray
> 
> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong  wrote:
>> The vastly better option is to obtain a prefix and ASN from ARIN and merely 
>> trade BGP with your
>> upstream providers.
>> 
>> Prefix translation comes with all the same disabilities that are present 
>> when you do this in IPv4.
>> 
>> In IPv4, everyone's software expects you to have a broken network (NAT) and 
>> there is lots of extra
>> code in all of the applications to work around this.
>> 
>> In iPv6, it is not unlikely that this code will eventually get removed and 
>> you will then have a high
>> level of application problems in your "prefix-translated" environment.
>> 
>> Owen
>> 
>> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote:
>> 
>>> Prefix translation looks to be exactly what we need to do here. Thanks for 
>>> all of the replies.
>>> 
>>> 
>>> -Randy
>>> 
>>> On Jun 12, 2011, at 2:42, Seth Mos  wrote:
>>> 
 
 Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven:
 
> 
> I have an interesting situation at a business that I am working on. We 
> currently have the office set up with redundant connections for their 
> mission critical servers and such, and also have a (cheap) cable modem 
> for general browsing on client machines.
 
 So basically policy routing?
 
> The interesting part is that the client machines need to access some 
> customer networks via the main redundant network, so we have a firewall 
> set up to route those connections via the redundant connections, and 
> everything else via the cheaper, faster cable modem. NAT is used on both 
> outbound connections.
 
 Yep that sounds like policy routing.
 
> With IPv6, we are having some trouble coming up with a way to do this. 
> Since there is no NAT, does anyone have any ideas as to how this could be 
> accomplished?
 
 Sure there is NAT, you can use prefix translation to translate your Global 
 Address Range from the redundant ISP to the Cable ISP Global address range 
 when leaving that interface. I've run a similar setup with 3 independent 
 ISPs with IPv6 netblocks.
 
 Whichever connection the traffic went out it got the right GUA mapped onto 
 it. Note that this is 1:1 NAT and not N:1.
 
 In my case there was no primary GUA range, I used a ULA on the LAN side of 
 things, and mapped the corresponding GUA onto it when leaving the network. 
 I had 3 rules, 1 for each WAN 

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 9:41 AM, Ray Soucy wrote:

> The energy in this thread should be focused on switch vendors to
> actually implement L2 security features for IPv6, which is usually an
> easy upgrade; rather than calling for all host implementations of IPv6
> to work differently; which will take a decade to implement and be a
> band-aid at best; not a good long-term design for the protocol.
> 

No, the energy in this thread needs to be directed to both of those
issues. However, your characterization of the needed behavior
and the time to deploy it is not entirely accurate.

What is needed is:

-   Native RA Guard in switches
-   Native DHCPv6 Snooping in switches
-   Native RA Guard in WAPs
-   Native DHCPv6 Snooping in WAPs
-   Additional options to DHCPv6 for Routing Information
-   Eventual changes to host DHCPv6 Client behavior so that
DHCP does occur when RA not present.

> I think that was the original spirit of this thread.
> 

No, the original spirit of the thread revolved around the last 2
items in the above list. The first 4 have been discussed and already
resolved at the IETF level and are merely awaiting vendor implementation.

> Full static assignment is always an option if you don't want to use RA
> or DHCPv6.
> 

Sure, but, the issue is people that don't want to use RA, but, want to use
DHCPv6.

> If you get a bad DHCP server on the network it can take hours to undo
> the damage thanks to lease times; if you get bad RA you can usually
> fix the problem as soon as you find it.  Apples and Oranges, really.
> If connecting the rogue DHCP server doesn't obviously break things
> when connected, you might not even notice it until it's too late.
> 

There's actually no reason this couldn't be done with DHCPv6, too, but,
it's not there currently.

> More responsive to change is better in my opinion.  I hate having to
> wait hours or days for changes to propagate; it feels like the 1990s,
> or the days of mainframes and batch jobs.
> 

Then use RA and move on. However, please understand that yours
is not the only environment and that there are real-world scenarios
where having the router-guys dictate the host configuration is considered
unacceptable at best.

Owen

> On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard  wrote:
>> On 14/06/2011 16:12, Ray Soucy wrote:
>>> 
>>> The point was you shouldn't base protocol design around the
>>> possibility that someone might tell it to do something you don't want
>>> it to do; otherwise you'll end up with a one-size-fits-all protocol
>>> that has zero flexibility (and might not even be functional at all).
>> 
>> sensible engineering dictates that design should aim to be fail-safe.  I.e.
>> not "failsafe" in the common usage of the term (= doesn't fail), but rather
>> cogniscent of the fact that all systems fail from time to time, and when
>> they do, they ought to fail in such a way that the collateral damage is
>> minimised.  This principal is recodified in various ways ("be liberal in
>> what you accept", etc), but the underlying idea is the same.
>> 
>> In IPv6-land, we appear not to have learned the lessons from ipv4 history,
>> and our vendors aren't yet shipping switches with native RA- and DHCPv6-
>> guard (yes, there are some exceptions to the former).
>> 
>> Nick
>> 
>> 
> 
> 
> 
> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/

Re: Question about migrating to IPv6 with multiple upstreams.

[Randy Carpenter]

> Why do people insist on creating solutions where each host has
> exactly one IPv6
> address, instead of letting each host have *three* (in this case) - a
> ULA and
> two provider-prefixed addresses?
> 

How does the upstream router control which address/path the client host use to 
route?

-Randy

Re: Question about migrating to IPv6 with multiple upstreams.

[Randy Carpenter]

> Hi Ray,
> 
> There's a nuance here you've missed.
> 
> There are two main reasons for ULA inside the network:
> 
> 1. Address stability (simplifies network management)
> 2. Source obfuscation (improves the depth of the security plan)
> 
> Option 1: Obfuscation desired.
> 
> ULA inside. NAT/PAT at both borders. You don't use prefix translation
> here because prefix translation does little obfuscation: it has a 1:1
> relationship with each individual host and still reveals the internal
> routing structure.
> 
> Option 2: Stability, no obfuscation desired.
> 
> ULA inside, prefix translation at both borders.
> 
> Option 3: Neither stability nor obfuscation required.
> 
> GUA from one of the providers inside. Prefix translation to the other
> provider for the connections desired out that border. Giving the
> hosts
> real GUA addresses maximizes application compatibility.

Why doesn't GUA give you address stability? I would think that it would provide 
the best stability.

And in terms of obfuscation, why couldn't we use DHCPv6 to give reasonably 
random addresses?

Also, I don't see how prefix translation reveals my internal routing structure.

I don't really see the point in ULA. It just seems like "The Return of RFC 
1918, Part II, the Sequel"


-Randy

Re: Question about migrating to IPv6 with multiple upstreams.

[Valdis . Kletnieks]

On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said:

> A better solution; and the one I think that will be adopted in the
> long term as soon as vendors come into the fold, is to swap out
> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
> policy routing to handle load balancing and failover the way most
> "dual WAN" multifunction firewalls do today.
> 
> Example:
> 
> Each provider provides a 48-bit prefix;
> 
> Internally you use a ULA prefix; and setup prefix translation so that
> the prefix gets swapped appropriately for each uplink interface.  This
> provides the benefits of "NAT" used today; without the drawback of
> having to do funky port rewriting and restricting incoming traffic to
> mapped assignments or UPnP.

Why do people insist on creating solutions where each host has exactly one IPv6
address, instead of letting each host have *three* (in this case) - a ULA and
two provider-prefixed addresses?


pgp2Q7o2t21SV.pgp
Description: PGP signature

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 9:18 AM, Nick Hilliard wrote:

> On 14/06/2011 17:02, Owen DeLong wrote:
>> That was kind of my point. You are unlikely to encounter such a large L2 
>> domain outside of an
>> exchange point.
> 
> Indeed so.  Apart from large enterprise LANs.  And campus LANs.  And badly 
> designed large service provider LANs.  And other types of large L2 domains.  
> But apart from those exceptions, you'll never see large L2 domains outside of 
> an IXP.
> 
> Nick

Even on large enterprise LANS, campus LANs, and badly designed large service 
provider LANs,
you don't tend to have the kind of perversely large L2 environment that is 
present at AMSIX.

Also, as was pointed out, they have a rather unique situation of stale peering 
sessions continuously
banging away at ND and ARP.

Owen

Re: Question about migrating to IPv6 with multiple upstreams.

[Ray Soucy]

I try to avoid the Obfuscation argument when I can.

I've seen people try to be smart by telling Law Enforcement that they
don't keep logs and can't point to which host was a problem behind a
NAT box, only to see Law Enforcement take all the PCs instead of the
one in question.  So it's always made me nervous.  As for the security
value; I think it's more a privacy value than anything.  But you can
accomplish almost the same thing by having those hosts use a web
proxy; which you likely want to be doing anyway so you can scan
content for threats.

I personally have no desire for it; but if someone wants to implement
it I won't stop them.

On Tue, Jun 14, 2011 at 1:28 PM, William Herrin  wrote:
> On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy  wrote:
>> I think in the long term telling everyone to jump into the BGP table
>> is not sustainable; and not operationally consistent with the majority
>> of SMB networks.
>>
>> A better solution; and the one I think that will be adopted in the
>> long term as soon as vendors come into the fold, is to swap out
>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
>> policy routing to handle load balancing and failover the way most
>> "dual WAN" multifunction firewalls do today.
>>
>> Example:
>>
>> Each provider provides a 48-bit prefix;
>>
>> Internally you use a ULA prefix; and setup prefix translation so that
>> the prefix gets swapped appropriately for each uplink interface.  This
>> provides the benefits of "NAT" used today; without the drawback of
>> having to do funky port rewriting and restricting incoming traffic to
>> mapped assignments or UPnP.
>
> Hi Ray,
>
> There's a nuance here you've missed.
>
> There are two main reasons for ULA inside the network:
>
> 1. Address stability (simplifies network management)
> 2. Source obfuscation (improves the depth of the security plan)
>
> Option 1: Obfuscation desired.
>
> ULA inside. NAT/PAT at both borders. You don't use prefix translation
> here because prefix translation does little obfuscation: it has a 1:1
> relationship with each individual host and still reveals the internal
> routing structure.
>
> Option 2: Stability, no obfuscation desired.
>
> ULA inside, prefix translation at both borders.
>
> Option 3: Neither stability nor obfuscation required.
>
> GUA from one of the providers inside. Prefix translation to the other
> provider for the connections desired out that border. Giving the hosts
> real GUA addresses maximizes application compatibility.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

Re: Question about migrating to IPv6 with multiple upstreams.

[William Herrin]

On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy  wrote:
> I think in the long term telling everyone to jump into the BGP table
> is not sustainable; and not operationally consistent with the majority
> of SMB networks.
>
> A better solution; and the one I think that will be adopted in the
> long term as soon as vendors come into the fold, is to swap out
> RFC1918 with ULA addressing, and swap out PAT with NPT; then use
> policy routing to handle load balancing and failover the way most
> "dual WAN" multifunction firewalls do today.
>
> Example:
>
> Each provider provides a 48-bit prefix;
>
> Internally you use a ULA prefix; and setup prefix translation so that
> the prefix gets swapped appropriately for each uplink interface.  This
> provides the benefits of "NAT" used today; without the drawback of
> having to do funky port rewriting and restricting incoming traffic to
> mapped assignments or UPnP.

Hi Ray,

There's a nuance here you've missed.

There are two main reasons for ULA inside the network:

1. Address stability (simplifies network management)
2. Source obfuscation (improves the depth of the security plan)

Option 1: Obfuscation desired.

ULA inside. NAT/PAT at both borders. You don't use prefix translation
here because prefix translation does little obfuscation: it has a 1:1
relationship with each individual host and still reveals the internal
routing structure.

Option 2: Stability, no obfuscation desired.

ULA inside, prefix translation at both borders.

Option 3: Neither stability nor obfuscation required.

GUA from one of the providers inside. Prefix translation to the other
provider for the connections desired out that border. Giving the hosts
real GUA addresses maximizes application compatibility.

Regards,
Bill Herrin


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

Re: Question about migrating to IPv6 with multiple upstreams.

[Ray Soucy]

Today you're probably correct.  If you want to have more than one
provider reliably you pretty much need to be doing BGP; or have some
sort of primary-backup setup to fail over from one to the other; or
give each host a global address from each provider (really not
desirable in the majority of networks).

I think in the long term telling everyone to jump into the BGP table
is not sustainable; and not operationally consistent with the majority
of SMB networks.

A better solution; and the one I think that will be adopted in the
long term as soon as vendors come into the fold, is to swap out
RFC1918 with ULA addressing, and swap out PAT with NPT; then use
policy routing to handle load balancing and failover the way most
"dual WAN" multifunction firewalls do today.

Example:

Each provider provides a 48-bit prefix;

Internally you use a ULA prefix; and setup prefix translation so that
the prefix gets swapped appropriately for each uplink interface.  This
provides the benefits of "NAT" used today; without the drawback of
having to do funky port rewriting and restricting incoming traffic to
mapped assignments or UPnP.

The firewall keeps track of if a connection is up or down and keeps
policy routing up to date;

You can choose to set it up to either load balance per-flow or as a
primary and backup interface.

You can handle DNS by using RFC 2136 updates for a sub-domain with a
short TTL on a hosted server to keep names up to date in the event of
a link drop.

This doesn't require cooperation from the provider; it doesn't require
knowledge of routing protocols; and it is easy to understand for
people used to the "NAT" environment.

Last time I checked, Linux still needs some work to handle ECMP
routing for IPv6, but once that is in place; combined with patches for
Network Prefix Translation (NPT), it should be trivial to implement.

My guess is within the next year we'll see something pop up that does this.

Ray

On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong  wrote:
> The vastly better option is to obtain a prefix and ASN from ARIN and merely 
> trade BGP with your
> upstream providers.
>
> Prefix translation comes with all the same disabilities that are present when 
> you do this in IPv4.
>
> In IPv4, everyone's software expects you to have a broken network (NAT) and 
> there is lots of extra
> code in all of the applications to work around this.
>
> In iPv6, it is not unlikely that this code will eventually get removed and 
> you will then have a high
> level of application problems in your "prefix-translated" environment.
>
> Owen
>
> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote:
>
>> Prefix translation looks to be exactly what we need to do here. Thanks for 
>> all of the replies.
>>
>>
>> -Randy
>>
>> On Jun 12, 2011, at 2:42, Seth Mos  wrote:
>>
>>>
>>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven:
>>>

 I have an interesting situation at a business that I am working on. We 
 currently have the office set up with redundant connections for their 
 mission critical servers and such, and also have a (cheap) cable modem for 
 general browsing on client machines.
>>>
>>> So basically policy routing?
>>>
 The interesting part is that the client machines need to access some 
 customer networks via the main redundant network, so we have a firewall 
 set up to route those connections via the redundant connections, and 
 everything else via the cheaper, faster cable modem. NAT is used on both 
 outbound connections.
>>>
>>> Yep that sounds like policy routing.
>>>
 With IPv6, we are having some trouble coming up with a way to do this. 
 Since there is no NAT, does anyone have any ideas as to how this could be 
 accomplished?
>>>
>>> Sure there is NAT, you can use prefix translation to translate your Global 
>>> Address Range from the redundant ISP to the Cable ISP Global address range 
>>> when leaving that interface. I've run a similar setup with 3 independent 
>>> ISPs with IPv6 netblocks.
>>>
>>> Whichever connection the traffic went out it got the right GUA mapped onto 
>>> it. Note that this is 1:1 NAT and not N:1.
>>>
>>> In my case there was no primary GUA range, I used a ULA on the LAN side of 
>>> things, and mapped the corresponding GUA onto it when leaving the network. 
>>> I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56.
>>>
>>> In your case you already have a primary connection of sorts, so I'd suggest 
>>> using that on the LAN side and only map the other GUA onto it when it 
>>> leaves the other interfaces.
>>>
>>> The policy routing rules on your firewall can make all the routing 
>>> decissions for you.
>>>
>>> If you search google for "IPv6 network prefix translation" there will be a 
>>> firewall listed that can do this somewhere in the middle of the page.
>>>
>>> Cheers,
>>>
>>> Seth
>>>
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the

Re: IPv6 - a noobs prespective

[Octavio Alvarez]

On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby  wrote:

I am however *terrified* of making that move. There is so many new  
phrases, words, things to think about etc


You fears will significantly lower after you set up a separate lab and
play with it. With something as simple as a switch you can make a simple
IPv6-only network. Try to replicate your current network in the lab as
far as you can, using the "new" concepts and techniques and understand
the current state of the art (read that as RA+DHCPv6, etc.) Get your
pings right.

This will automatically get you to dual-stacking, as in "how do I make
both protocols work in the same physical network?". They just do. At
this point the problem stops belonging to the network infrastructure
and it passes on to the application servers and hosts.

(And ask your ISP to support IPv6).

Good luck.

--
Octavio.

Re: The stupidity of trying to "fix" DHCPv6

[Ray Soucy]

The energy in this thread should be focused on switch vendors to
actually implement L2 security features for IPv6, which is usually an
easy upgrade; rather than calling for all host implementations of IPv6
to work differently; which will take a decade to implement and be a
band-aid at best; not a good long-term design for the protocol.

I think that was the original spirit of this thread.

Full static assignment is always an option if you don't want to use RA
or DHCPv6.

Presenting suggestions in the form of an RFC draft would be more
useful than ranting about it for the 100th time on-list.  At least
then you could point to something that can actually be worked on
constructively; rather than a lot of straw-man arguments because you
don't personally like the way things are currently done.

If you get a bad DHCP server on the network it can take hours to undo
the damage thanks to lease times; if you get bad RA you can usually
fix the problem as soon as you find it.  Apples and Oranges, really.
If connecting the rogue DHCP server doesn't obviously break things
when connected, you might not even notice it until it's too late.

More responsive to change is better in my opinion.  I hate having to
wait hours or days for changes to propagate; it feels like the 1990s,
or the days of mainframes and batch jobs.

On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard  wrote:
> On 14/06/2011 16:12, Ray Soucy wrote:
>>
>> The point was you shouldn't base protocol design around the
>> possibility that someone might tell it to do something you don't want
>> it to do; otherwise you'll end up with a one-size-fits-all protocol
>> that has zero flexibility (and might not even be functional at all).
>
> sensible engineering dictates that design should aim to be fail-safe.  I.e.
> not "failsafe" in the common usage of the term (= doesn't fail), but rather
> cogniscent of the fact that all systems fail from time to time, and when
> they do, they ought to fail in such a way that the collateral damage is
> minimised.  This principal is recodified in various ways ("be liberal in
> what you accept", etc), but the underlying idea is the same.
>
> In IPv6-land, we appear not to have learned the lessons from ipv4 history,
> and our vendors aren't yet shipping switches with native RA- and DHCPv6-
> guard (yes, there are some exceptions to the former).
>
> Nick
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

Re: The stupidity of trying to "fix" DHCPv6

[Nick Hilliard]

On 14/06/2011 17:02, Owen DeLong wrote:

That was kind of my point. You are unlikely to encounter such a large L2 domain 
outside of an
exchange point.


Indeed so.  Apart from large enterprise LANs.  And campus LANs.  And badly 
designed large service provider LANs.  And other types of large L2 domains. 
 But apart from those exceptions, you'll never see large L2 domains 
outside of an IXP.


Nick

Re: The stupidity of trying to "fix" DHCPv6

[Nick Hilliard]

On 14/06/2011 16:12, Ray Soucy wrote:

The point was you shouldn't base protocol design around the
possibility that someone might tell it to do something you don't want
it to do; otherwise you'll end up with a one-size-fits-all protocol
that has zero flexibility (and might not even be functional at all).


sensible engineering dictates that design should aim to be fail-safe.  I.e. 
not "failsafe" in the common usage of the term (= doesn't fail), but rather 
cogniscent of the fact that all systems fail from time to time, and when 
they do, they ought to fail in such a way that the collateral damage is 
minimised.  This principal is recodified in various ways ("be liberal in 
what you accept", etc), but the underlying idea is the same.


In IPv6-land, we appear not to have learned the lessons from ipv4 history, 
and our vendors aren't yet shipping switches with native RA- and DHCPv6- 
guard (yes, there are some exceptions to the former).


Nick

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 1:48 AM, Mikael Abrahamsson wrote:

> On Tue, 14 Jun 2011, Owen DeLong wrote:
> 
>> ND would be a far more frequent occurrence than DHCP requests.
> 
> Of course, it was only partly related to the discussion, most likely the 
> network which has problem with multicast would break first because of ND, not 
> because of DHCPv6 requests.
> 
>> Also, I tend to doubt that ANYONE would do DHCP on an exchange point 
>> network, so, it's not exactly an applicable example environment.
> 
> It's the largest IPv6 enabled L2 domain I've experienced :P
> 

Indeed, it tends to be a perversely large L2 domain, but, not one where DHCP 
would likely occur.

That was kind of my point. You are unlikely to encounter such a large L2 domain 
outside of an
exchange point.

Owen

Re: The stupidity of trying to "fix" DHCPv6

[Ray Soucy]

Wow, I don't recall making it personal?

I have broken networks before by connecting miss-configured devices,
by the way, and I was a moron for doing so.  I don't base my network
design decisions around preventing people with full access to
configure the network breaking it; but rather restrict the level of
access people have and impingement sane policies on when and how
changes are made; like most of the people on this list.

The point was you shouldn't base protocol design around the
possibility that someone might tell it to do something you don't want
it to do; otherwise you'll end up with a one-size-fits-all protocol
that has zero flexibility (and might not even be functional at all).
Similar problems existed in IPv4; but over time networks evolved and
better protection methods became available.

The days of the dumb switch are over; and at the price and performance
of today's switches we should expect features like RA guard and MLD
snooping to be standard.  We threw out Ethernet hubs a decade or two
ago for good reason, and there was resistance then too.

On a side note, if you're going to resort to direct personal attacks,
maybe you shouldn't be doing so while representing your company.
Everything on NANOG is archived and sticks around for a very, very
long time.

Ray

On Fri, Jun 10, 2011 at 3:21 PM, Steve Clark  wrote:
> On 06/10/2011 09:37 AM, Ray Soucy wrote:
>
> You really didn't just write an entire post saying that RA is bad
> because if a moron of a network engineer plugs an incorrectly
> configured device into a production network it may cause problems, did
> you?
>
>
> You are the moron - this stuff happens and wishing it didn't doesn't stop
> it. Get a clue!
>
> Honestly.  This whole argument is getting ridiculous.
>
> On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell  wrote:
>
> In a message written on Fri, Jun 10, 2011 at 01:03:01PM +, Bjoern A.
> Zeeb wrote:
>
> On Jun 10, 2011, at 10:10 AM, sth...@nethelp.no wrote:
>
> Several large operators have said, repeatedly, that they want to use
> DHCPv6 without RA. I disagree that this is stupid.
>
> I wonder if it's just a "violation" of rule #1: stop thinking legacy!
>
> People are used to what they have done for a decade or two.  It's hard to
> see the change and results in "why is this all so different and
> complicated?".
> It's hard to open ones mind for the new, but it is essential to do with new
> technology.
>
> The problem in this case is that the failure modes are significantly
> different.  Some folks have learned this the hard way.
>
> It's a very easy scenario to reconstruct.  Consider the "branch
> office router" in a typical corporate enviornment.  We're talking
> a device with one WAN port, and one LAN port.  Configure it for
> dual stack, speaking IPv4, and in IPv4 configure it the typical
> corporate way with a "DHCP Helper" forwarding requests over the WAN
> to a central DHCP server.  In IPv6, configure it with RA's, the
> supposed "better" way.
>
> Now, take the 100% working branch router and have it sent back to
> corporate.  Maybe they got a bigger router, maybe the office closed.
> A network engineer gets the router and is tasked with making it
> ready to redeploy.
>
> The network engineer plugs it into the switch on his desktop, plugs in a
> serial cable, turns it on and steps out to get a coffee while it boots.
> He's planning to erase the configuration and then load new software over
> the network.
>
> As soon as the router boots the IPv6 network fails for all the users on
> his subnet.  IPv4 keeps working fine.
>
> Oops.
>
> What happened?  Well, the router sent IPv6 RA's as soon as it came
> up, and every workstation instantly started using them.  In IPv4,
> the router received DHCPv4 requests and forwarded them per the
> helper address, except that its WAN port is down, and thus it in
> fact didn't send them anywhere.
>
> The important points:
>
> - IPv4 "failed safe" with the DHCP config.  This "rogue device" will
>  never disrupt the IPv4 configuration.  DHCP snooping isn't even needed
>  in your switches, since it never returns a response.
>
> - IPv6 "failed immediately" with the RA configuration.  What's worse is
>  if you simply turn the device off after you realized you took down the
>  entire network devices will continue to be broken for 2-4 hours until
>  the RA's time out.  The only method to mitigate is to deploy RA guard
>  on all of your switches, which probably means replacing 100% of your
>  hardware with new stuff that can do that, and then deploying new
>  features.
>
> The fact of the matter is that the failure modes of these two
> protocols are vastly different operationally.  The DHCP failure
> semantics are not only better understood, but cause less disruption
> to the network.  Even a properly rouge DHCP server will only damage
> _new_ clients coming up on a network, existing folks will work just
> fine.  Contrast with RA's which instantly break 100% of the users.
>
> Even more annoying is th

Re: AUS?

[Jay Ashworth]

- Original Message -
> From: "Santino Codispoti" 

> Is there a nanogish group that covers AUS?

As it happens, we have a page *just* for this list at outages.org...

and Oz is, as you might expect, the first item on the list:

  http://www.outages.org/index.php/Network_ops_group_websites

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: The stupidity of trying to "fix" DHCPv6

[Iljitsch van Beijnum]

On 14 jun 2011, at 10:20, Mikael Abrahamsson wrote:

> On the AMSIX peering LAN there is more than 100pps of ND traffic (at least 
> there was when we checked). Since they do not do IPv6 multicast intelligent 
> handling (MLD snooping I guess) certain highend (legacy) router platforms run 
> into trouble because all these packets are punted to RP.

That is really pathetic. I thought that any Ethernet chip built the previous 
decade could filter 64 or so multicast addresses in hardware. Only when you're 
subscribed to more multicast groups than what your Ethernet chip can filter in 
hardware does the software for an IPv4-only system have to encounter IPv6 
multicasts, or an IPv6 system random neighbor solicitations, which are load 
balanced over a wide range of multicast addresses just for this reason.

Also strange that there would be this much neighbor discovery traffic, probably 
the same reason AMS-IX used to have 15 kbps of ARP traffic: stale BGP peerings 
to addresses that no longer exist.

Is a postmaster from csod.com/cornerstoneondemand.com present?

[Jason Gurtz]

la4prd4.mx.csod.com seems to be having trouble saying helo/ehlo and
disconnects after our welcome banner

Users think we're blocking training registration emails from your large
wholesale energy customer in the N.E. area; we're not.

Please get in touch. 860.823.4118 if email fails.

~JasonG

Re: The stupidity of trying to "fix" DHCPv6

[Leo Bicknell]

In a message written on Tue, Jun 14, 2011 at 10:20:07AM +0200, Mikael 
Abrahamsson wrote:
> On the AMSIX peering LAN there is more than 100pps of ND traffic (at least 
> there was when we checked). Since they do not do IPv6 multicast 
> intelligent handling (MLD snooping I guess) certain highend (legacy) 
> router platforms run into trouble because all these packets are punted to 
> RP.

Note that an exchange point LAN is a bit of an odd duck.  RA's are
supposed to be disabled.  There is no DHCP.

Rather, the ND behavior is casued by people statically configuring
BGP sessions and then a participant leaving.  So ND (or even ARP)
tries over and over to find the missing participant.

The thing to investigate here is if ND rate limiting is implemented
correctly by the vendors involved, similar to ARP rate limiting.  I'm
not sure if there are standards requirements that could be in play as
well.

I'm not sure this has anything to do with the RA/DHCP issues...

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


pgp3sJn4cl35i.pgp
Description: PGP signature

Re: The stupidity of trying to "fix" DHCPv6

[Mikael Abrahamsson]

On Tue, 14 Jun 2011, Owen DeLong wrote:


ND would be a far more frequent occurrence than DHCP requests.


Of course, it was only partly related to the discussion, most likely the 
network which has problem with multicast would break first because of ND, 
not because of DHCPv6 requests.


Also, I tend to doubt that ANYONE would do DHCP on an exchange point 
network, so, it's not exactly an applicable example environment.


It's the largest IPv6 enabled L2 domain I've experienced :P

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

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 14, 2011, at 1:20 AM, Mikael Abrahamsson wrote:

> On Tue, 14 Jun 2011, Owen DeLong wrote:
> 
>> You would need an AWFUL lot of hosts for this to add up to a few 100pps (or 
>> even 10pps) of multicast traffic.
> 
> On the AMSIX peering LAN there is more than 100pps of ND traffic (at least 
> there was when we checked). Since they do not do IPv6 multicast intelligent 
> handling (MLD snooping I guess) certain highend (legacy) router platforms run 
> into trouble because all these packets are punted to RP.
> 
> Implementing access list that filtered all multicast traffic the linecard 
> didn't actually subscribe to, solved the problem.

ND would be a far more frequent occurrence than DHCP requests.

Also, I tend to doubt that ANYONE would do DHCP on an exchange point network, 
so, it's not exactly
an applicable example environment.

Owen

Re: Question about migrating to IPv6 with multiple upstreams.

[Owen DeLong]

On Jun 13, 2011, at 9:28 PM, William Herrin wrote:

> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong  wrote:
>> The vastly better option is to obtain a prefix and ASN from ARIN and merely 
>> trade BGP with your
>> upstream providers.
> 
> My "(cheap) cable modem for general browsing" provider wouldn't even
> delegate RDNS; they'd only put PTRs in *their* servers. Swap BGP
> routes with them? Swell dream.
> 
Or work around it with a free tunnel to a nearby tunnel service that does
support BGP and will give you a /48.

> This has become a common strategy: the cheap, fast, commodity service
> for the most-of-the-time that it's working and the most-of-the-stuff
> that it works for combined with the expensive and slow but reliable
> and full featured service for the mission critical apps. One of these
> isn't going to come with BGP and a PI prefix, and the technologies we
> deploy are going to have to deal with that.
> 

Yep. For IPv6, there are options.


Owen

Re: The stupidity of trying to "fix" DHCPv6

[Mikael Abrahamsson]

On Tue, 14 Jun 2011, Owen DeLong wrote:

You would need an AWFUL lot of hosts for this to add up to a few 100pps 
(or even 10pps) of multicast traffic.


On the AMSIX peering LAN there is more than 100pps of ND traffic (at least 
there was when we checked). Since they do not do IPv6 multicast 
intelligent handling (MLD snooping I guess) certain highend (legacy) 
router platforms run into trouble because all these packets are punted to 
RP.


Implementing access list that filtered all multicast traffic the linecard 
didn't actually subscribe to, solved the problem.

Re: AUS?

[Scott Weeks]

--- santino.codisp...@gmail.com wrote:
From: Santino Codispoti 

Is there a nanogish group that covers AUS?
--


First hit on a search engine: "australia network operator group".

www.ausnog.net

scott

AUS?

[Santino Codispoti]

Is there a nanogish group that covers AUS?

Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong]

On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote:

> On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell  wrote:
>> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van 
>> Beijnum wrote:
>>> Like I said before, that would pollute the network with many multicasts 
>>> which can seriously degrade wifi performance.
>> 
>> Huh?  This is no worse than IPv4 where a host comes up and sends a
>> subnet-broadcast to get DHCP.
> 
> Broadcast != Multicast.  esp. when talking about wireless chipsets.  I've yet 
> to find a wifi chipset that didn't completely fuck-up when presented with 
> even a low pps of multicast traffic.  Broadcast traffic doesn't seem to 
> bother them -- it doesn't attempt to filter them in any way, or really pay 
> them any attention.  If I had to guess, the chip firmware is individually 
> transmitting multicast packets to each peer; a broadcast packet is sent once 
> to all peers.
> 
> I've not had any wireless networks disrupted by broadcast traffic -- and with 
> Radware load balancers in the network, there are *plenty* of broadcasts 
> (ARP).  Just a few 100pps of multicast and the AP fails. (linksys, netgear, 
> even cisco... all broadcom crap radios.)
> 
> --Ricky

You would need an AWFUL lot of hosts for this to add up to a few 100pps (or 
even 10pps) of multicast
traffic.

Owen