Re: using "reserved" IPv6 space

[Karl Auer]

On Mon, 2012-07-16 at 23:44 -0700, Owen DeLong wrote:
> The whole concept of gratuitous arp is strictly IPv4.

Isn't an unsolicited neighbour advertisement pretty much the same thing?

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687


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

Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 11:16 PM, Jimmy Hess wrote:

> On 7/17/12, Karl Auer  wrote:
> [snip
>> I'm not sure I follow the logic there. If the anycast router changes the
>> packet will be resent to the new subnet anycast router eventually
>> (assuming some layer cares enough about the packet to resend it). The
>> "last known hardware address" doesn't matter any more or less in this
>> scenario than it does in any other routing situation.
> 
> The pertinent discussion is not about "any other routing situation";
> it's about first hop redundancy.
> 
> The "last known hardware address" is in the NDP table, so the packet
> retransmissions likely wind up in the same place

NUD should actually take care of that.

> Another problem is the subnet anycast address may find unwanted
> routers that have to listen on it, including routers with only one
> interface and  incomplete routing info,  and including some
> unauthorized   5-port   IPv6  router  someone smuggled into the
> building and plugged in somewhere.

Yep.

> By contrast, a real  FHRP  that implements failover either uses a
> virtual hardware address, or a 'gratuitous arp' type mechanism,  so
> the packet retransmissions will go to the live failover partner.

The whole concept of gratuitous arp is strictly IPv4.

Owen

Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 10:36 PM, Seth Mos wrote:

> Hi,
> 
> Op 16 jul 2012, om 18:34 heeft valdis.kletni...@vt.edu het volgende 
> geschreven:
> 
>> On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
>>> ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be 
>>> there
>>> if there weren't enough customers asking for it. Are all the customers 
>>> naive?
>>> I doubt it. They have their reasons. I agree with your "purist" definition 
>>> and
>>> did not say I was using it. My point is that vendors are still rolling out 
>>> base
>>> line features even today.
>> 
>> Sorry to tell you this, but the customers *are* naive and asking for stupid
>> stuff. They think they need NAT under IPv6 because they suffered with it in
>> IPv4 due to addressing issues or a (totally percieved) security benefit (said
>> benefit being *entirely* based on the fact that once you get NAT working, you
>> can build a stateful firewall for essentially free).  The address crunch is
>> gone, and stateful firewalls exist, so there's no *real* reason to keep
>> pounding your head against the wall other than "we've been doing it for 15
>> years".
> 
> To highlight what the current NAT66 is useful for, it's a RFC for Network 
> Prefix translation. It has nothing do with obfuscation or hiding the network 
> anymore. It's current application is multihoming for the poor.

And it's a really poor way to do multihoming.

You don't have to spend a lot of money to multihome properly.

> 
> Example:
> You have a Cable and a DSL, they both provide IPv6 and you want to provide 
> failover. You then use ULA or one of the Global Addresses on the LAN network, 
> and set up NAT66 mappings for the secondary WAN, or both if you are using ULA.

I have that and I use BGP with an ARIN prefix using the Cable and DSL as layer 
2 substrates for dual-stack tunnels.

Works pretty well and doesn't cost much more than the NAT66 based solution.

> This will not hide *anything* as your machines will now be *visible* on 2 
> global prefixes at the same time. And yes, you still use the stateful 
> firewall rules on each WAN for the incoming traffic. And you can redirect 
> traffic as needed out each WAN. It's the closest thing to the existing Dual 
> WAN that current routers support.
> 
> Also note that this also works fine with 2 IPv6 tunnels. Bind each tunnel to 
> a WAN and you have the same failover for IPv6 as IPv4.

Once you go to tunnels, why not go all the way and put BGP across the tunnels?

Owen

Re: NAT66 was Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 10:20 PM, valdis.kletni...@vt.edu wrote:

> On Mon, 16 Jul 2012 21:31:42 -0700, Owen DeLong said:
>> Think HA pairs in Pittsburgh, Dallas, and San Jose.
>> 
>> Now imagine each has different upstream connectivity and the backbone
>> network connecting all the corporate sites lives inside those firewalls.
>> 
>> The real solution to this is to move the backbone outside of the firewalls
>> and connect the internal networks via VPNS that ride the external backbone
>> and can be routed over the internet safely when a backbone link fails.
> 
> Wouldn't this be even easier if you gave each machine involved multiple
> addresses, one ULA and one external?  This isn't IPv4 anymore, you can
> stick multiple addresses on an interface. :)

Not really... Doesn't help with the situation where you go from
host->Firewall A-> web server on the external internet
and the response goes
web server->Firewall B-> X (Firewall B has no state table entry for the 
session).

Owen

Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 9:40 PM, Karl Auer wrote:

> On Mon, 2012-07-16 at 23:38 -0400, Matt Addison wrote:
>> Oliver  wrote:
>>> Additionally, as an alternative to RAs, you can simply point default
>>> at the all-routers anycast address.
>> 
>> Wouldn't this result in duplicate packets leaving your network if
>> there were more than 1 router listening to 'all routers' and you (at
>> the MAC layer) multicasted to those listeners?
> 
> I think Oliver meant the subnet router anycast address.
> 
> Anycast gets you to one-of-many. The routers work out which of them is
> currently getting the subnet router anycast traffic. If that router
> drops out for any reason, another of the routers available on the link
> takes over.
> 

Reread the spec... It gets the packet to one or more of the routers and it may 
well
lead to packet duplication. There may or may not be coordination between the
routers. It isn't in the spec.

Owen

Re: using "reserved" IPv6 space

[Jimmy Hess]

On 7/17/12, Karl Auer  wrote:
[snip
> I'm not sure I follow the logic there. If the anycast router changes the
> packet will be resent to the new subnet anycast router eventually
> (assuming some layer cares enough about the packet to resend it). The
> "last known hardware address" doesn't matter any more or less in this
> scenario than it does in any other routing situation.

The pertinent discussion is not about "any other routing situation";
it's about first hop redundancy.

The "last known hardware address" is in the NDP table, so the packet
retransmissions likely wind up in the same place

Another problem is the subnet anycast address may find unwanted
routers that have to listen on it, including routers with only one
interface and  incomplete routing info,  and including some
unauthorized   5-port   IPv6  router  someone smuggled into the
building and plugged in somewhere.


By contrast, a real  FHRP  that implements failover either uses a
virtual hardware address, or a 'gratuitous arp' type mechanism,  so
the packet retransmissions will go to the live failover partner.

--
-JH

Re: NAT66 was Re: using "reserved" IPv6 space

[Seth Mos]

Op 17 jul 2012, om 04:56 heeft Grant Ridder het volgende geschreven:

> If you are running an HA pair, why would you care which box it went back
> through?

Because it could be/is a stateful firewall and the backup will drop the 
traffic. (FreeBSD CARP)

Cheers,

Seth

> 
> -Grant
> 
> On Monday, July 16, 2012, Mark Andrews wrote:
> 
>> 
>> In message > squumzofs3_-yrihy8o4gt3w9+x6f...@mail.gmail.com >, Lee
>> writes:
>>> On 7/16/12, Owen DeLong > wrote:
 
 Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
>> being
 able to eliminate NAT. NAT was a necessary evil for IPv4 address
 conservation. It has no good use in IPv6.
>>> 
>>> NAT is good for getting the return traffic to the right firewall.  How
>>> else do you deal with multiple firewalls & asymmetric routing?
>> 
>> Traffic goes where the routing protocols direct it.  NAT doesn't
>> help this and may actually hinder as the source address cannot be
>> used internally to direct traffic to the correct egress point.
>> 
>> Instead you need internal routers that have to try to track traffic
>> flows rather than making simple decisions based on source and
>> destination addresess.
>> 
>> Applications that use multiple connections may not always end up
>> with consistent external source addresses.
>> 
>>> Yes, it's possible to get traffic back to the right place without NAT.
>>> But is it as easy as just NATing the outbound traffic at the
>>> firewall?
>> 
>> It can be and it can be easier to debug without NAT mangling
>> addresses.
>> 
>> The only thing helpful NAT66 does is delay the externally visible
>> source address selection until the packet passes the NAT66 box.
>> 
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>> 
>> 

Re: using "reserved" IPv6 space

[Seth Mos]

Hi,

Op 16 jul 2012, om 18:34 heeft valdis.kletni...@vt.edu het volgende geschreven:

> On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
>> ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
>> if there weren't enough customers asking for it. Are all the customers naive?
>> I doubt it. They have their reasons. I agree with your "purist" definition 
>> and
>> did not say I was using it. My point is that vendors are still rolling out 
>> base
>> line features even today.
> 
> Sorry to tell you this, but the customers *are* naive and asking for stupid
> stuff. They think they need NAT under IPv6 because they suffered with it in
> IPv4 due to addressing issues or a (totally percieved) security benefit (said
> benefit being *entirely* based on the fact that once you get NAT working, you
> can build a stateful firewall for essentially free).  The address crunch is
> gone, and stateful firewalls exist, so there's no *real* reason to keep
> pounding your head against the wall other than "we've been doing it for 15
> years".

To highlight what the current NAT66 is useful for, it's a RFC for Network 
Prefix translation. It has nothing do with obfuscation or hiding the network 
anymore. It's current application is multihoming for the poor.

Example:
You have a Cable and a DSL, they both provide IPv6 and you want to provide 
failover. You then use ULA or one of the Global Addresses on the LAN network, 
and set up NAT66 mappings for the secondary WAN, or both if you are using ULA.

This will not hide *anything* as your machines will now be *visible* on 2 
global prefixes at the same time. And yes, you still use the stateful firewall 
rules on each WAN for the incoming traffic. And you can redirect traffic as 
needed out each WAN. It's the closest thing to the existing Dual WAN that 
current routers support.

Also note that this also works fine with 2 IPv6 tunnels. Bind each tunnel to a 
WAN and you have the same failover for IPv6 as IPv4.

Cheers,

Seth

Re: using "reserved" IPv6 space

[Karl Auer]

On Tue, 2012-07-17 at 00:10 -0500, Jimmy Hess wrote:
> Just to reaffirm that.Rfc 4291  states packets sent to the
> subnet-router anycast will be delivered to one router on the subnet.
> [...]
> But what about packets with a destination address on another network
> and trying to use the anycast address as a 'gateway'?   The
> destination IP in the IP packet header of the forwarded packet won't
> be the anycast address;  the last known hardware address for the IP,
> if it's unicast,  may be down,   so it's probably nonsensical to enter
> an anycast address as default gateway,  unless  using the subnet
> anycast address as a router/gateway  has special behavior defined
> elsewhere?

I'm not sure I follow the logic there. If the anycast router changes the
packet will be resent to the new subnet anycast router eventually
(assuming some layer cares enough about the packet to resend it). The
"last known hardware address" doesn't matter any more or less in this
scenario than it does in any other routing situation.

Regards, K.
 
-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687


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

Re: NAT66 was Re: using "reserved" IPv6 space

[valdis . kletnieks]

On Mon, 16 Jul 2012 21:31:42 -0700, Owen DeLong said:
> Think HA pairs in Pittsburgh, Dallas, and San Jose.
>
> Now imagine each has different upstream connectivity and the backbone
> network connecting all the corporate sites lives inside those firewalls.
>
> The real solution to this is to move the backbone outside of the firewalls
> and connect the internal networks via VPNS that ride the external backbone
> and can be routed over the internet safely when a backbone link fails.

Wouldn't this be even easier if you gave each machine involved multiple
addresses, one ULA and one external?  This isn't IPv4 anymore, you can
stick multiple addresses on an interface. :)


pgpC6tH5tmUNf.pgp
Description: PGP signature

Re: using "reserved" IPv6 space

[Jimmy Hess]

On 7/16/12, Karl Auer  wrote:
> I think Oliver meant the subnet router anycast address.
> Anycast gets you to one-of-many. The routers work out which of them is

Just to reaffirm that.Rfc 4291  states packets sent to the
subnet-router anycast will be delivered to one router on the subnet.
  That's fine for traffic with a destination IP of the anycast
address; they'll land on one of the routers, and perhaps one of the
routers will respond.

But what about packets with a destination address on another network
and trying to use the anycast address as a 'gateway'?   The
destination IP in the IP packet header of the forwarded packet won't
be the anycast address;  the last known hardware address for the IP,
if it's unicast,  may be down,   so it's probably nonsensical to enter
an anycast address as default gateway,  unless  using the subnet
anycast address as a router/gateway  has special behavior defined
elsewhere?


RFC 4291 S2.6.1
http://tools.ietf.org/html/rfc4291
"
   Packets sent to the Subnet-Router anycast address will be delivered
   to one router on the subnet.  All routers are required to support the
   Subnet-Router anycast addresses for the subnets to which they have
   interfaces.

"
--
-JH

Re: using "reserved" IPv6 space

[Karl Auer]

On Mon, 2012-07-16 at 23:38 -0400, Matt Addison wrote:
>  Oliver  wrote:
> > Additionally, as an alternative to RAs, you can simply point default
> > at the all-routers anycast address.
> 
> Wouldn't this result in duplicate packets leaving your network if
> there were more than 1 router listening to 'all routers' and you (at
> the MAC layer) multicasted to those listeners?

I think Oliver meant the subnet router anycast address.

Anycast gets you to one-of-many. The routers work out which of them is
currently getting the subnet router anycast traffic. If that router
drops out for any reason, another of the routers available on the link
takes over.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687


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

Re: NAT66 was Re: using "reserved" IPv6 space

[Owen DeLong]

Think HA pairs in Pittsburgh, Dallas, and San Jose.

Now imagine each has different upstream connectivity and the backbone
network connecting all the corporate sites lives inside those firewalls.

The real solution to this is to move the backbone outside of the firewalls
and connect the internal networks via VPNS that ride the external backbone
and can be routed over the internet safely when a backbone link fails.

However, this still requires some interesting effort in terms of source address
selection, routing, etc. in order to avoid triangle routing out of the firewall
in Pittsburgh resulting in a return trying to come in via Dallas or San Jose.

I think in IPv6, as firewall vendors begin ot mature their products, we'll
either see a departure from stateful inspection, or, more likely an ability
to set up HA clusters across diverse geography where state tables are
kept in sync across the WAN.

Owen

On Jul 16, 2012, at 7:56 PM, Grant Ridder wrote:

> If you are running an HA pair, why would you care which box it went back
> through?
> 
> -Grant
> 
> On Monday, July 16, 2012, Mark Andrews wrote:
> 
>> 
>> In message > squumzofs3_-yrihy8o4gt3w9+x6f...@mail.gmail.com >, Lee
>> writes:
>>> On 7/16/12, Owen DeLong > wrote:
 
 Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
>> being
 able to eliminate NAT. NAT was a necessary evil for IPv4 address
 conservation. It has no good use in IPv6.
>>> 
>>> NAT is good for getting the return traffic to the right firewall.  How
>>> else do you deal with multiple firewalls & asymmetric routing?
>> 
>> Traffic goes where the routing protocols direct it.  NAT doesn't
>> help this and may actually hinder as the source address cannot be
>> used internally to direct traffic to the correct egress point.
>> 
>> Instead you need internal routers that have to try to track traffic
>> flows rather than making simple decisions based on source and
>> destination addresess.
>> 
>> Applications that use multiple connections may not always end up
>> with consistent external source addresses.
>> 
>>> Yes, it's possible to get traffic back to the right place without NAT.
>>> But is it as easy as just NATing the outbound traffic at the
>>> firewall?
>> 
>> It can be and it can be easier to debug without NAT mangling
>> addresses.
>> 
>> The only thing helpful NAT66 does is delay the externally visible
>> source address selection until the packet passes the NAT66 box.
>> 
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>> 
>> 

Re: using "reserved" IPv6 space

[Owen DeLong]

You could try this:


If you give a /48 to each site, then assign the sites primary and backup 
firewalls.

Aggregate the /48s into larger blocks by primary firewall.

Aggregate the primary firewall bocks into larger backup firewall aggregates.

Advertise the firewall-specific aggregates and the less specific 
backup-firewall set
aggregates.

Owen

On Jul 16, 2012, at 7:04 PM, Lee wrote:

> On 7/15/12, John Levine  wrote:
>>> I feel like I should be able to do something really nice with an
>>> absurdly large address space.  But lack of imagination or whatever.. I
>>> haven't come up with anything that really appeals to me.
>> 
>> Use a fresh IP for every HTTP request, email message, and IM.  Just think of
>> how well you can do error management.
> 
> hrmm...  nope, can't think of a single thing.  Then again, I'm on the
> routing & switching team at work, so things like HTTP requests, email
> messages, and IM are just different types of user traffic that needs
> to be routed to me.
> 
> Recall the message I was responding to:
> 
 There is a HUGE difference between IPv4 and IPv6 thinking.  We've all
 been living in an austerity regime for so long that we've completely
 forgotten how to leave parsimony behind.  Even those of us who worked
 at companies that were summarily handed a Class B when we mumbled
 something about "internal subnetting" have a really hard time
 remembering how to act when we suddenly don't have to answer for every
 single host address and can design a network to conserve other things
 (like our brain cells).
> 
> I read it as design a network >>addressing scheme<< to conserve other
> things & was hoping someone could share new ways of looking at it.  I
> feel like I'm stuck in "IPv4 think" with an addressing plan that's
> basically
> 
> Each site gets a /48.  Even the ones with less than 200 people.
> Each subnet is assigned a /64 except for loopbacks & p2p subnets.
> First 256 subnets in each /48 are reserved for things like loopback
> addresses, p2p links, switch management subnets, etc.
> High order 4 bits of the site address are used for the subnet type.
> So a /52 tells you the site and if it's users, printers, servers, IP
> phones, or whatever.
> 
> Which is *boring*.  Nothing novel, no breaking out of "IPv4 think"
> aside from massively wasting address space.  Which brings me back
> around to my original request for suggestions.  What's the new way of
> looking at designing a network addressing scheme?
> 
> Regards,
> Lee

Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 7:35 PM, Karl Auer wrote:

> On Mon, 2012-07-16 at 22:04 -0400, Lee wrote:
>> Each site gets a /48.  Even the ones with less than 200 people.
>> [...]
>> Which is *boring*.  Nothing novel, no breaking out of "IPv4 think"
>> aside from massively wasting address space.
> 
> It's only a waste if you get nothing for it. By using /64 everywhere you
> get a more homogeneous network, easier to administer, manage, document,
> maintain... There are similar advantages, writ larger, to using /48 for
> every site.
> 

It's also a waste if you don't ever use the address and the protocol gets 
deprecated
before a significant percentage of the addresses are allocated.

Earlier in this thread, I did the math showing how it will likely, even with 
very liberal
allocation policies, be 100 years or more before we allocate 1/40th of the total
IPv6 space to RIRs.

> Whether you have 2, 20, 200, 2000 or 20,000 hosts in a /64 subnet, you
> have still only used 0% of it, to a dozen or more decimal places.
> IPv4-think says that's a waste. IPv6-think says "great - all my subnets
> are large enough". Resizing IPv4 subnets is common; resizing IPv6
> subnets will be rare.
> 
> IPv4-think is conserving addresses. IPv6-think is conserving subnets. We
> don't buy dining chairs based on the number of atoms in them - we buy
> enough to seat the people who need seating.
> 
Exactly.

Owen

Re: NAT66 was Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 6:55 PM, Lee wrote:

> On 7/16/12, Owen DeLong  wrote:
>> 
>> Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
>> able to eliminate NAT. NAT was a necessary evil for IPv4 address
>> conservation. It has no good use in IPv6.
> 
> NAT is good for getting the return traffic to the right firewall.  How
> else do you deal with multiple firewalls & asymmetric routing?

1.  Share state across the firewalls or go with stateless firewalls.
2.  Move the firewalls close enough to the end hosts to avoid this problem,
Keep the asymmetric routing outside the perimeter.
3.  Very creative source address selection mechanisms.
4.  LISP (if you must).

> 
> Yes, it's possible to get traffic back to the right place without NAT.
> But is it as easy as just NATing the outbound traffic at the
> firewall?

That depends on whose life you are trying to make easy. If you asked the
application developers or the people that have to build all the problematic
ALGs that creates a need for, I'd bet they would have a different opinion
than the guy configuring the firewall.

In terms of overall problems created, cost to the community, increased 
insecurity,
and the other costs associated with a NAT-based solution, I'd say that it is
a net loss to use NAT and a net gain to avoid it.

From the perspective of the firewall administrator alone without a broader
view of the total consequences, toxic pollution of the internet seems like
a good idea.

Owen

Re: using "reserved" IPv6 space

[Jimmy Hess]

On 7/16/12, -Hammer-  wrote:
> hurdles.  Example? HSRP IPv6 global addressing on Cisco ASR platform. If
HSRP is a legacy proprietary protocol;  try VRRP.   Stateless
autoconfig and router advertisements can obviate (eliminate/reduce)
the need in many cases;  albeit,  with a longer failure recovery
duration.

> this morning from CheckPoint for NAT66. This should have been ready for
> prime time years ago. I guess the vendors weren't getting the push from

NAT66;  you're talking about something that is not a mainline feature,
an experimental proposition; RFC6296  produced in 2011.   Very few
IPv6 deployments should require prefix translation or any kind of NAT
technology  with IPv6,  other than the IPv4 transition technologies.

So... NO..  they should not have had this ready "for prime time" years ago.

There are other things they should have been working on,  such as
getting the base IPv6 implementation correct, V6 connectivity,
V6-enabled protocols, support for the newer RA/DHCPv6 options,  and
support for the newer more fully baked IPv4 transition specs such as
6to4, NAT-PT,  and bugfixing.

I'll take the stable platform,  that has the standards-specified
features,  over one with bells and whistles, and the latest
experimental  draft features such as 6to6,  that are not required to
deploy IPv6,  thanks.

--
-JH

Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 12:39 PM, Oliver wrote:

> On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
>> On the HSRP/ND part , this all falls in the First Hop redundancy areana
>> and can be achieved via any of the following and each has its merits and
>> cons..
>> 
>> 1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
>> faster failover
>> 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP)
>> 3) Default route selection.
>> 
> 
> In all honesty, I think using ND as the failover method is a generally bad 
> idea - you have no way of ensuring all endpoints take note of or honour the 
> router preference flag.

Huh? Any host which doesn't is provably buggy. I'm not saying it can't or won't
happen, but, seriously? If the host is that buggy, you can't count on it using
the fake MAC either.

> Additionally, having a 1 second validity lifetime is going to create a lot of 
> ICMPv6 spam across the segment - big deal? perhaps not. But when contrasted 
> with the fact that it can be wholly avoided using one of the aforementioned 
> redundancy protocols, why would you do it?

You don't need a 1 second valid timer (that would be absurd). You need a
1 second keep alive (if you really care about 1 second fast fall-over) and 
you're
going to get just as much SPAM with sub-second fallover from any of the other
solutions as well. They all send multicast packets.

> Additionally, as an alternative to RAs, you can simply point default at the 
> all-routers anycast address.

The disadvantage to this is the high probability of packet duplication. For
someone worried about ICMP spam on the subnet, I'm surprised you're not
worried about what happens when 2 or more routers copy the same packet
and route both copies on to the end destination. (Lather, rinse, repeat said
duplication for any upstream segments using such tactics as well).

Owen

Re: St Louis Internet Exchange

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 07/16/2012 07:36 PM, Bill Woodcock wrote:
> 
> On Jul 16, 2012, at 3:23 PM, Jay Hanke wrote:
> 
>> After a bit of googling, I found some references to an Internet 
>> Exchange in St. Louis, MO called the St. Louis Regional
>> Exchange. Is this project still active?
> 
> It appears to be dead.  The web site redirects to a commercial
> colo, and the last few ISPs appear to have departed at the end of
> 2008, after about two years of activity.
> 
> https://prefix.pch.net/applications/ixpdir/detail.php?exchange_point_id=350
>
>  If anyone has any better information, please let us know.
> 
> -Bill
- 
IXP DBs are coming out empty. I understand these DBs are best effort
but what I like about PCH that it tends to never drop an exchange from
the list and instead marks it as "defunct" or "down" by performing
some sort of validation which Bill could confirm.

In addition to IXP DBs, IRR, LGs & bgp tables (route view & ripe ris)
shows no sign either.


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAE5gUACgkQ3HuimOHfh+FRbwD+NLNDFPc+ru2x3fIYJ0gDKuZU
K77j6h8jxrJXwtOSduIA/i09nBAalPPK1fCii+z0swTE6Upj4dWqRA9osFTjwNN5
=iW4R
-END PGP SIGNATURE-

Re: using "reserved" IPv6 space

[Matt Addison]

On Jul 16, 2012, at 15:40, Oliver
 wrote:

> Additionally, as an alternative to RAs, you can simply point default at the
> all-routers anycast address.

Wouldn't this result in duplicate packets leaving your network if
there were more than 1 router listening to 'all routers' and you (at
the MAC layer) multicasted to those listeners?

Re: NAT66 was Re: using "reserved" IPv6 space

[Mark Andrews]

In message 
, Grant 
Ridder writes:
> 
> If you are running an HA pair, why would you care which box it went back
> through?
> 
> -Grant

It still doesn't change the arguement.  You still need to have flow
based routers or you may choose the wrong egress point and if you
need NAT66 you have 4+ upstream connections though two of them may
be tunnels.  You also need a protocol to keep the HA pair state
tables in sync.

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

Re: NAT66 was Re: using "reserved" IPv6 space

[Grant Ridder]

If you are running an HA pair, why would you care which box it went back
through?

-Grant

On Monday, July 16, 2012, Mark Andrews wrote:

>
> In message  squumzofs3_-yrihy8o4gt3w9+x6f...@mail.gmail.com >, Lee
> writes:
> > On 7/16/12, Owen DeLong > wrote:
> > >
> > > Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
> being
> > > able to eliminate NAT. NAT was a necessary evil for IPv4 address
> > > conservation. It has no good use in IPv6.
> >
> > NAT is good for getting the return traffic to the right firewall.  How
> > else do you deal with multiple firewalls & asymmetric routing?
>
> Traffic goes where the routing protocols direct it.  NAT doesn't
> help this and may actually hinder as the source address cannot be
> used internally to direct traffic to the correct egress point.
>
> Instead you need internal routers that have to try to track traffic
> flows rather than making simple decisions based on source and
> destination addresess.
>
> Applications that use multiple connections may not always end up
> with consistent external source addresses.
>
> > Yes, it's possible to get traffic back to the right place without NAT.
> > But is it as easy as just NATing the outbound traffic at the
> > firewall?
>
> It can be and it can be easier to debug without NAT mangling
> addresses.
>
> The only thing helpful NAT66 does is delay the externally visible
> source address selection until the packet passes the NAT66 box.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
>

Re: NAT66 was Re: using "reserved" IPv6 space

[Mark Andrews]

In message 
, Lee 
writes:
> On 7/16/12, Owen DeLong  wrote:
> >
> > Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
> > able to eliminate NAT. NAT was a necessary evil for IPv4 address
> > conservation. It has no good use in IPv6.
> 
> NAT is good for getting the return traffic to the right firewall.  How
> else do you deal with multiple firewalls & asymmetric routing?

Traffic goes where the routing protocols direct it.  NAT doesn't
help this and may actually hinder as the source address cannot be
used internally to direct traffic to the correct egress point.

Instead you need internal routers that have to try to track traffic
flows rather than making simple decisions based on source and
destination addresess.

Applications that use multiple connections may not always end up
with consistent external source addresses.

> Yes, it's possible to get traffic back to the right place without NAT.
> But is it as easy as just NATing the outbound traffic at the
> firewall?

It can be and it can be easier to debug without NAT mangling
addresses.

The only thing helpful NAT66 does is delay the externally visible
source address selection until the packet passes the NAT66 box.

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

Re: St Louis Internet Exchange

[Bill Woodcock]

On Jul 16, 2012, at 3:23 PM, Jay Hanke wrote:

> After a bit of googling, I found some references to an Internet
> Exchange in St. Louis, MO called the St. Louis Regional Exchange.
> Is this project still active?

It appears to be dead.  The web site redirects to a commercial colo, and the 
last few ISPs appear to have departed at the end of 2008, after about two years 
of activity.

https://prefix.pch.net/applications/ixpdir/detail.php?exchange_point_id=350

If anyone has any better information, please let us know.

-Bill





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: using "reserved" IPv6 space

[Karl Auer]

On Mon, 2012-07-16 at 22:04 -0400, Lee wrote:
> Each site gets a /48.  Even the ones with less than 200 people.
> [...]
> Which is *boring*.  Nothing novel, no breaking out of "IPv4 think"
> aside from massively wasting address space.

It's only a waste if you get nothing for it. By using /64 everywhere you
get a more homogeneous network, easier to administer, manage, document,
maintain... There are similar advantages, writ larger, to using /48 for
every site.

Whether you have 2, 20, 200, 2000 or 20,000 hosts in a /64 subnet, you
have still only used 0% of it, to a dozen or more decimal places.
IPv4-think says that's a waste. IPv6-think says "great - all my subnets
are large enough". Resizing IPv4 subnets is common; resizing IPv6
subnets will be rare.

IPv4-think is conserving addresses. IPv6-think is conserving subnets. We
don't buy dining chairs based on the number of atoms in them - we buy
enough to seat the people who need seating.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687


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

Re: using "reserved" IPv6 space

[Lee]

On 7/15/12, John Levine  wrote:
>>I feel like I should be able to do something really nice with an
>>absurdly large address space.  But lack of imagination or whatever.. I
>>haven't come up with anything that really appeals to me.
>
> Use a fresh IP for every HTTP request, email message, and IM.  Just think of
> how well you can do error management.

hrmm...  nope, can't think of a single thing.  Then again, I'm on the
routing & switching team at work, so things like HTTP requests, email
messages, and IM are just different types of user traffic that needs
to be routed to me.

Recall the message I was responding to:

>>> There is a HUGE difference between IPv4 and IPv6 thinking.  We've all
>>> been living in an austerity regime for so long that we've completely
>>> forgotten how to leave parsimony behind.  Even those of us who worked
>>> at companies that were summarily handed a Class B when we mumbled
>>> something about "internal subnetting" have a really hard time
>>> remembering how to act when we suddenly don't have to answer for every
>>> single host address and can design a network to conserve other things
>>> (like our brain cells).

I read it as design a network >>addressing scheme<< to conserve other
things & was hoping someone could share new ways of looking at it.  I
feel like I'm stuck in "IPv4 think" with an addressing plan that's
basically

Each site gets a /48.  Even the ones with less than 200 people.
Each subnet is assigned a /64 except for loopbacks & p2p subnets.
First 256 subnets in each /48 are reserved for things like loopback
addresses, p2p links, switch management subnets, etc.
High order 4 bits of the site address are used for the subnet type.
So a /52 tells you the site and if it's users, printers, servers, IP
phones, or whatever.

Which is *boring*.  Nothing novel, no breaking out of "IPv4 think"
aside from massively wasting address space.  Which brings me back
around to my original request for suggestions.  What's the new way of
looking at designing a network addressing scheme?

Regards,
Lee

NAT66 was Re: using "reserved" IPv6 space

[Lee]

On 7/16/12, Owen DeLong  wrote:
>
> Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
> able to eliminate NAT. NAT was a necessary evil for IPv4 address
> conservation. It has no good use in IPv6.

NAT is good for getting the return traffic to the right firewall.  How
else do you deal with multiple firewalls & asymmetric routing?

Yes, it's possible to get traffic back to the right place without NAT.
 But is it as easy as just NATing the outbound traffic at the
firewall?

Lee

RE: Real world sflow vs netflow?

[James Braunegg]

Dear David

>From a visibility point of view, we obtain as much information as we require 
>to know exactly what's occurring on our network where and when in real-time.

We know what's happening, on any interface on any network at any time. - that 
being said for us the most important visibility is all about the flow of 
traffic and packet counts the security side should be done at the firewall 
level ! 

If anyone wants a demo of our sFlow setup happy to show you via a team viewer 
session or something !

By the way we are using sFlow now

Kindest Regards


James Braunegg
W:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
E:   james.braun...@micron21.com  |  ABN:  12 109 977 666   



This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.


-Original Message-
From: David Hubbard [mailto:dhubb...@dino.hostasaurus.com] 
Sent: Tuesday, July 17, 2012 8:26 AM
To: nanog@nanog.org
Subject: RE: Real world sflow vs netflow?

From: James Braunegg [mailto:james.braun...@micron21.com] 
> 
> Dear All
> 
> Around a year ago I had the same debate sflow vs netflow vs snmp port 
> counters. read lots of stories lots of myths lots of good information.  
> My Conclusion
> 
> In the end I did real life testing comparing each platform
> 
> We routed live traffic (about 250mbits) from our Cisco 7200
> G2 routers though Brocade MLXe routers and exported netflow from the 
> Cisco platform and sFlow from the Brocade platform.
> 
> Each router sent netflow/sflow traffic to two collectors on 
> independent hardware (same specifications) running the same collection 
> netflow analyzer software.
> 
> The end result was after hours of testing, or even days and weeks of 
> testing there was no significant difference between traffic volumes 
> netflow was showing vs slfow. Ie less than 0.5% variance between each 
> environment.
> 
> That being said both netflow and sflow both under read by about 3% 
> when compared to snmp port counters, which we put to the conclusion 
> was broadcast traffic etc which the routers didn't see / flow.
> 
> Regardless if you're going to bill from netflow or sflow in our test 
> environment we saw no  significant difference between either platform.

What are your thoughts on the non-billing aspects after your comparison 
testing; if you are/were using it for those purposes?
We don't use our current netflow for billing, just for security investigation 
and (ideally) early alerting of abnormal activity like port scans, compromised 
apps on servers, etc.

Thanks,

David

RE: Real world sflow vs netflow?

[David Hubbard]

From: James Braunegg [mailto:james.braun...@micron21.com] 
> 
> Dear All
> 
> Around a year ago I had the same debate sflow vs netflow vs 
> snmp port counters. read lots of stories lots of myths lots 
> of good information.  My Conclusion
> 
> In the end I did real life testing comparing each platform
> 
> We routed live traffic (about 250mbits) from our Cisco 7200 
> G2 routers though Brocade MLXe routers and exported netflow 
> from the Cisco platform and sFlow from the Brocade platform.
> 
> Each router sent netflow/sflow traffic to two collectors on 
> independent hardware (same specifications) running the same 
> collection netflow analyzer software.
> 
> The end result was after hours of testing, or even days and 
> weeks of testing there was no significant difference between 
> traffic volumes netflow was showing vs slfow. Ie less than 
> 0.5% variance between each environment.
> 
> That being said both netflow and sflow both under read by 
> about 3% when compared to snmp port counters, which we put to 
> the conclusion was broadcast traffic etc which the routers 
> didn't see / flow.
> 
> Regardless if you're going to bill from netflow or sflow in 
> our test environment we saw no  significant difference 
> between either platform.

What are your thoughts on the non-billing aspects after your
comparison testing; if you are/were using it for those purposes?
We don't use our current netflow for billing, just for security
investigation and (ideally) early alerting of abnormal activity
like port scans, compromised apps on servers, etc.

Thanks,

David

St Louis Internet Exchange

[Jay Hanke]

After a bit of googling, I found some references to an Internet
Exchange in St. Louis, MO called the St. Louis Regional Exchange.

Is this project still active?

Thanks,

Jay

Re: using "reserved" IPv6 space

[Rajendra Chayapathi (rchayapa)]

True .. Your point of the ICMPv6 storm is on mark and is one of the
drawbacks for this solution.

On 7/16/12 12:39 PM, "Oliver" 
wrote:

>On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
>> On the HSRP/ND part , this all falls in the First Hop redundancy areana
>> and can be achieved via any of the following and each has its merits and
>> cons..
>> 
>> 1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
>> faster failover
>> 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP)
>> 3) Default route selection.
>> 
>
>In all honesty, I think using ND as the failover method is a generally
>bad 
>idea - you have no way of ensuring all endpoints take note of or honour
>the 
>router preference flag.
>
>Additionally, having a 1 second validity lifetime is going to create a
>lot of 
>ICMPv6 spam across the segment - big deal? perhaps not. But when
>contrasted 
>with the fact that it can be wholly avoided using one of the
>aforementioned 
>redundancy protocols, why would you do it?
>
>Additionally, as an alternative to RAs, you can simply point default at
>the 
>all-routers anycast address.
>
>Regards,
>Oliver
>

RE: Real world sflow vs netflow?

[James Braunegg]

Dear All

Around a year ago I had the same debate sflow vs netflow vs snmp port counters. 
read lots of stories lots of myths lots of good information.  My Conclusion

In the end I did real life testing comparing each platform

We routed live traffic (about 250mbits) from our Cisco 7200 G2 routers though 
Brocade MLXe routers and exported netflow from the Cisco platform and sFlow 
from the Brocade platform.

Each router sent netflow/sflow traffic to two collectors on independent 
hardware (same specifications) running the same collection netflow analyzer 
software.

The end result was after hours of testing, or even days and weeks of testing 
there was no significant difference between traffic volumes netflow was showing 
vs slfow. Ie less than 0.5% variance between each environment.

That being said both netflow and sflow both under read by about 3% when 
compared to snmp port counters, which we put to the conclusion was broadcast 
traffic etc which the routers didn't see / flow.

Regardless if you're going to bill from netflow or sflow in our test 
environment we saw no  significant difference between either platform.

Hope that helps
Kindest Regards


James Braunegg
W:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
E:   james.braun...@micron21.com  |  ABN:  12 109 977 666   



This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.


-Original Message-
From: Nick Hilliard [mailto:n...@foobar.org] 
Sent: Monday, July 16, 2012 6:53 AM
To: nanog@nanog.org
Subject: Re: Real world sflow vs netflow?

On 14/07/2012 09:30, Łukasz Bromirski wrote:
> And that's the biggest problem with sFlow. Packets are sampled, not 
> flows. You may miss the big or important flow, you don't have 
> visibility into every conversation going through the device.

Unless you enable sampling, which is pretty much necessary for non-trivial 
traffic volumes.

> NetFlow supports IPv6. As well as L2 traffic (v9), MPLS, multicast and 
> so on.

It does, depending on hardware variety, but you need specific platform support 
for each packet variety (v4 / v6 / mpls / etc), and platform support for this 
can be very dodgy.  You don't need this with sflow - it just punts 1 in N raw 
packets out to your collector, and the statistical assumptions which were made 
by the networking device are well documented.
I've never seen documentation on the sampling technique used for each netflow 
implementation.

> The measurements provided by sFlow are only approximation of the real 
> traffic and while it may be acceptable on LAN links where details 
> don't matter as much, it's hardly good enough to present a real view 
> on the WAN links.
> 
> sFlow was built to work on switches and provide "some" accuracy, it's 
> not good enough (unless you do sampling on a 1:5-1:10 basis) to do 
> billing or some detailed analysis of traffic:

Depends on how detailed your requirements are.  For billing, most people don't 
classify by packet analysis, but rather by byte count which can be handled by 
snmp port counters.  If you need to do something fancier, non-sampled netflow 
is indeed good enough for billing.

> http://www.inmon.com/pdf/sFlowBilling.pdf
> 
> You can use it to *estimate* the traffic, detect DDoS, sure. But the 
> data & scaling used by sFlow (and additionally tricks used by ASIC 
> vendors implementing it in the hardware) can't change the fundamental 
> difference - sFlow is really sPacket, as it doesn't deal with flows.

agreed, the name is wrong.

> NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling 
> accuracy and things like that, but working with flows is more accurate.

Depends on your use case.  For large traffic values, you run into the law of 
large numbers and you can get accurate visibility into what's happening on your 
network.

Certainly, netflow _can_ offer amazingly precise visibility into your network.  
But the trade-off is that you need specialised hardware to do this on your line 
cards or your forwarding engine.  This drives up both the capex (extra 
hardware) and the opex (tcam is power hungry) of your network.
 sflow is much cheaper to implement as you're not maintaining any state on your 
chassis.  You're just picking out a packet every so often.

The current generation of high end service provider hardware (juniper mx-3d, 
cisco sup2t / n7k / asr9k) is pretty much the first generation of hardware 
which doesn't have crippling netflow limitations, such as poor support for v6 / 
mpls, too small cache sizes, etc.  This fact alone should provide a good 
indication of how difficult it is to implement it well on fast boxes.

sflow is simpler, cheaper and i

Re: using "reserved" IPv6 space

[Oliver]

On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
> On the HSRP/ND part , this all falls in the First Hop redundancy areana
> and can be achieved via any of the following and each has its merits and
> cons..
> 
> 1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
> faster failover
> 2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP)
> 3) Default route selection.
> 

In all honesty, I think using ND as the failover method is a generally bad 
idea - you have no way of ensuring all endpoints take note of or honour the 
router preference flag.

Additionally, having a 1 second validity lifetime is going to create a lot of 
ICMPv6 spam across the segment - big deal? perhaps not. But when contrasted 
with the fact that it can be wholly avoided using one of the aforementioned 
redundancy protocols, why would you do it?

Additionally, as an alternative to RAs, you can simply point default at the 
all-routers anycast address.

Regards,
Oliver

Re: using "reserved" IPv6 space

[Fred Baker (fred)]

On Jul 13, 2012, at 8:05 AM, TJ wrote:

> On Fri, Jul 13, 2012 at 10:38 AM, -Hammer-  wrote:
> 
>> OK. I'm pretty sure I'm gonna get some flak for this but I'll share this
>> question and it's background anyway. Please be gentle.
>> 
>> In the past, with IPv4, we have used reserved or "non-routable" space
>> Internally in production for segments that won't be seen anywhere else.
>> Examples? A sync VLAN for some FWs to share state. An IBGP link between
>> routers that will never be seen or advertised. In those cases, we have
>> often used 192.0.2.0/24. It's reserved and never used and even if it did
>> get used one day we aren't "routing" it internally. It's just on segments
>> where we need some L3 that will never be seen.
>> 
>> On to IPv6
>> 
>> I was considering taking the same approach. Maybe using 0100::/8 or
>> 1000::/4 or A000::/3 as a space for this.
>> 
> 
> 
> Would using "just" Link Locals not be sufficient?

If they're on the same link, of course. My understanding of the question said 
"they're not on the same link".

> *(Failing that, as others noted, ULAs are the next "right" answer ... )*
> *
> *
> /TJ

Re: using "reserved" IPv6 space

[Rajendra Chayapathi (rchayapa)]

On the HSRP/ND part , this all falls in the First Hop redundancy areana
and can be achieved via any of the following and each has its merits and
cons..

1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
faster failover
2) Using any of the First hop redundancy protocol ( HSRP, VRRP , GLBP)
3) Default route selection.

So depending on the network convergence need  etc , any  or combination of
above can be looked at.

Thx
Rajendra 


On 7/16/12 9:09 AM, "-Hammer-"  wrote:

>Inline -
>
>-Hammer-
>
>"I was a normal American nerd"
>-Jack Herer
>
>
>1) (This one is currently a personal issue) I am still building up a true
>IPv6 skillset. Yes, I understand it for the most part but now is the time
>to apply it.
>
>Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is
>to start applying what you don't know and see what happens. For the most
>part, you will find that it is truly "96 more bits, no magic".
>
>--- Completely agree. Been playing in GNS3 on the basics and we're
>starting to play in a full lab soon.
>
>> 2) All the reading you do doesn't prepare you for application and the
>>vendors aren't necessarily helping. Feature parity across platforms and
>>vendors beyond just "interface x/x/x" and "ipv6 address
>>fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to
>>take what I understand and apply it beyond the basics I often see
>>hurdles.  Example? HSRP IPv6 global addressing on Cisco ASR platform. If
>>it's working for you hit me offline. Example2? Any vendor product beyond
>>a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN
>>guys may be rolling deep in IPv6 but not everyone else. I just got an EA
>>this morning from CheckPoint for NAT66. This should have been ready for
>>prime time years ago. I guess the vendors weren't getting the push from
>>the customers so there was no need to make an effort
>
>You probably meant 2001:db8:b1aa:b1aa::babe:1  (blah isn't hex and
>fe80::/10 is link local. 2001:db8::/16 is the example prefix)
>
>--- I stand corrected. :)
>
>   For the most part, HSRP really isn't even necessary or useful in IPv6
>since ND should take care of what HSRP did for IPv4.
>
>
>--- On the WAN? Sure. On my Internet facing equipment? I disagree.
>RAs and ND and all that fun stuff needs to be suppressed.
>  
>
>  I believe F5 has rolled out IPv6 in a subset of their products and that
>you need pretty recent versions to get IPv6 functionality from them. The
>ARIN Wiki (http://www.getipv6.info) may be a good source of information
>on various vendor statuses. Contribute what you know/find out there as
>well, please.
>
>
>--- Yes they have and NetScaler is running solid as well. My issues
>are when you go beyond basic features of any product with IPv6 things get
>tricky. I need content switching with redirects and whatnot and based on
>the few efforts I've seen so far I'm not optimistic. Again, routers and
>switches seem to be further ahead than other products. They all have
>their limits in advanced features. Back to my ASR comment.
>  
>
>Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
>being able to eliminate NAT. NAT was a necessary evil for IPv4 address
>conservation. It has no good use in IPv6.
>
>
>---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be
>there if there weren't enough customers asking for it. Are all the
>customers naive? I doubt it. They have their reasons. I agree with your
>"purist" definition and did not say I was using it. My point is that
>vendors are still rolling out baseline features even today.
>
>> 3) When I'm not preoccupied attempting to digest the fundamentals I am
>>well aware of the retooling of the brain that is required for this in a
>>network design. Last year I reached out to Team Cymru and attempted to
>>build an IPv6 router template to match their IPv4 template. It was a
>>completely different animal. Ironically most of the STIGs and NSA
>>reference garbage I used was ten years old but still applied. After
>>going thru all those docs my brain hurt trying to orient my ACLs
>>properly and go thru all the different attributes you want to block
>>where and when. Then I spent some time trying to work our design schemas
>>for our ARIN space with the WAN design team. What I'm trying to say is
>>that Roberts comments are spot on. It is a very different way of
>>thinking on a small scale and a large scale and you can't take your IPv4
>>logic and apply it. I've tried and it's just slowing me down.
>
>Yes and no. If you have been doing IPv4 long enough to remember pre-NAT
>IPv4, then, you just need to remember some of the old ways of IPv4. If
>you have no recollection of IPv4 without NAT, then, you are correct, it
>is a huge paradigm shift to go back to the way the internet is supposed
>to have been before we ran out of addresses.
>
>
>--- This isn't specific to you Owen, but the group in general. I have
>been around for a while. Not as 

Re: using "reserved" IPv6 space

[Ray Soucy]

"""
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
being able to eliminate NAT. NAT was a necessary evil for IPv4 address
conservation. It has no good use in IPv6.
"""

NAT still has its uses; virtualization and cloud infrastructure being
one of the most legitimate.

Certain kinds of NAT, such as RFC 6296, are very useful, and one of
the best methods we have today of delivering IPv6 to smaller networks
who wish to have private address space internally ... be it for
consistency, ISP independence, multi-homing, or just downright
operational parity.

I really think all this focus on anti-NAT talk has held-back adoption
(and FWIW I used to be one of the people banging the anti-NAT drum the
loudest).

Keep in mind the collective attitude in communities like this one
about NAT for v6 trickles down into decisions made elsewhere; the
Linux Netfilter team, for example, is met by a lot of hostility when
they talk about including things like 6296 in ip6tables; and as a
result it's been left out (even though it's functional).




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

RE: IPv6 Toolkit v1.2: Latest snapshot, and git repo

[Thomas York]

Also compiles and works fine for me on 10.7.

-- Thomas York

-Original Message-
From: Randy Carpenter [mailto:rcar...@network1.net]
Sent: Monday, July 16, 2012 11:21 AM
To: Fernando Gont
Cc: NANOG
Subject: Re: IPv6 Toolkit v1.2: Latest snapshot, and git repo


Appears to compile file on Mac OS X 10.7. The resulting programs run, but I 
have not tried any real testing with actual data.


thanks,
-Randy


- Original Message -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Folks,
>
> I've posted a snapshot (tarball) of my working copy of the IPv6
> toolkit. The tarball is available at:
> 
>
> Additionally, I've created a git repository for the toolkit, such that
> collaboration is improved. The git repo is available at:
> 
>
> If you have access to a Mac OS box, please try to compile the tools,
> and let me know if you find any errors (or let me know if they
> compiled cleanly). If you can also run the tools according to some of
> the examples in the manuals (and report any problems), that would be
> great, too.
>
> P.S.: If you've sent patches and your patches have not yet been
> applied, most likely it just means that I'm catching-up with them
> (feel free to resend!).
>
> Thanks!
>
> Best regards,--
> Fernando Gont
> e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJQAtn3AAoJEJbuqe/Qdv/xYIgH+wTQXJ3iNEnGnA0cMazS32py
> 3HfTdcMaEphnfF2a15dq1h/uqF05g3t9KqU744A1XmMtDlChvQ2I77uj2amqaeKi
> dED6e/NTuVAxTAI0ZTPIEn7BkDgtqvhuaoth+E4SX73lJC9eJR7e3T3BAtbESZaQ
> Sp67lvtgYmqogDc0IQALGNucyhHmacfUBocVLVgmVPn8BwdFxHI80W+Vc6TnKfjm
> Yc9ijgUPLTu0hOGD4bpOeQ2V3Dzw9PW17PyJlPr3TzWLzb8g64/zZROtHjXl/V4s
> 0JNAZVrHNDvA7kfEujzsoLcnQLCfq3+jzecvXcGwgsYMDXRBL8Lv628OAhrVglY=
> =Z3+1
> -END PGP SIGNATURE-
>
>
>



smime.p7s
Description: S/MIME cryptographic signature

Re: using "reserved" IPv6 space

[-Hammer-]

I agree. Most are naive. Not all.

-Hammer-

"I was a normal American nerd"
-Jack Herer

On 7/16/2012 11:34 AM, valdis.kletni...@vt.edu wrote:

On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:

---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
if there weren't enough customers asking for it. Are all the customers naive?
I doubt it. They have their reasons. I agree with your "purist" definition and
did not say I was using it. My point is that vendors are still rolling out base
line features even today.

Sorry to tell you this, but the customers *are* naive and asking for stupid
stuff. They think they need NAT under IPv6 because they suffered with it in
IPv4 due to addressing issues or a (totally percieved) security benefit (said
benefit being *entirely* based on the fact that once you get NAT working, you
can build a stateful firewall for essentially free).  The address crunch is
gone, and stateful firewalls exist, so there's no *real* reason to keep
pounding your head against the wall other than "we've been doing it for 15
years".

Re: using "reserved" IPv6 space

[valdis . kletnieks]

On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
> ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
> if there weren't enough customers asking for it. Are all the customers naive?
> I doubt it. They have their reasons. I agree with your "purist" definition and
> did not say I was using it. My point is that vendors are still rolling out 
> base
> line features even today.

Sorry to tell you this, but the customers *are* naive and asking for stupid
stuff. They think they need NAT under IPv6 because they suffered with it in
IPv4 due to addressing issues or a (totally percieved) security benefit (said
benefit being *entirely* based on the fact that once you get NAT working, you
can build a stateful firewall for essentially free).  The address crunch is
gone, and stateful firewalls exist, so there's no *real* reason to keep
pounding your head against the wall other than "we've been doing it for 15
years".



pgpcxuvjg9XU2.pgp
Description: PGP signature

Re: using "reserved" IPv6 space

[-Hammer-]

Inline -

-Hammer-

"I was a normal American nerd"
-Jack Herer


1) (This one is currently a personal issue) I am still building up a true IPv6 
skillset. Yes, I understand it for the most part but now is the time to apply 
it.

Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is to start 
applying what you don't know and see what happens. For the most part, you will find that 
it is truly "96 more bits, no magic".

--- Completely agree. Been playing in GNS3 on the basics and we're starting 
to play in a full lab soon.


2) All the reading you do doesn't prepare you for application and the vendors aren't necessarily 
helping. Feature parity across platforms and vendors beyond just "interface x/x/x" and 
"ipv6 address fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to take 
what I understand and apply it beyond the basics I often see hurdles.  Example? HSRP IPv6 global 
addressing on Cisco ASR platform. If it's working for you hit me offline. Example2? Any vendor 
product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN guys may be 
rolling deep in IPv6 but not everyone else. I just got an EA this morning from CheckPoint for 
NAT66. This should have been ready for prime time years ago. I guess the vendors weren't getting 
the push from the customers so there was no need to make an effort


You probably meant 2001:db8:b1aa:b1aa::babe:1  (blah isn't hex and fe80::/10 is 
link local. 2001:db8::/16 is the example prefix)

--- I stand corrected. :)

  For the most part, HSRP really isn't even necessary or useful in IPv6 since 
ND should take care of what HSRP did for IPv4.


--- On the WAN? Sure. On my Internet facing equipment? I disagree. RAs and 
ND and all that fun stuff needs to be suppressed.
 


 I believe F5 has rolled out IPv6 in a subset of their products and that you 
need pretty recent versions to get IPv6 functionality from them. The ARIN Wiki 
(http://www.getipv6.info) may be a good source of information on various vendor 
statuses. Contribute what you know/find out there as well, please.


--- Yes they have and NetScaler is running solid as well. My issues are 
when you go beyond basic features of any product with IPv6 things get tricky. I 
need content switching with redirects and whatnot and based on the few efforts 
I've seen so far I'm not optimistic. Again, routers and switches seem to be 
further ahead than other products. They all have their limits in advanced 
features. Back to my ASR comment.
 


Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able 
to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It 
has no good use in IPv6.


---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there if there 
weren't enough customers asking for it. Are all the customers naive? I doubt it. They 
have their reasons. I agree with your "purist" definition and did not say I was 
using it. My point is that vendors are still rolling out baseline features even today.


3) When I'm not preoccupied attempting to digest the fundamentals I am well 
aware of the retooling of the brain that is required for this in a network 
design. Last year I reached out to Team Cymru and attempted to build an IPv6 
router template to match their IPv4 template. It was a completely different 
animal. Ironically most of the STIGs and NSA reference garbage I used was ten 
years old but still applied. After going thru all those docs my brain hurt 
trying to orient my ACLs properly and go thru all the different attributes you 
want to block where and when. Then I spent some time trying to work our design 
schemas for our ARIN space with the WAN design team. What I'm trying to say is 
that Roberts comments are spot on. It is a very different way of thinking on a 
small scale and a large scale and you can't take your IPv4 logic and apply it. 
I've tried and it's just slowing me down.


Yes and no. If you have been doing IPv4 long enough to remember pre-NAT IPv4, 
then, you just need to remember some of the old ways of IPv4. If you have no 
recollection of IPv4 without NAT, then, you are correct, it is a huge paradigm 
shift to go back to the way the internet is supposed to have been before we ran 
out of addresses.


--- This isn't specific to you Owen, but the group in general. I have been 
around for a while. Not as long as some others here. NAT is a feature and it 
does have a place. Security. I'm sorry that this frustrates people but security 
is a layered approach and it starts off simple. If you have a network that 
doesn't need exposure to the Internet or to someone else you can get fancy with 
anything from a FW to control source and destination or AD controls so only the 
accounting team can get in. Sure. They all work. You can also NAT them. Make 
them invisible. Or null the traffic. The more fundamental the point of defense 
is the easier it is to understand and some

Re: using "reserved" IPv6 space

[Owen DeLong]

On Jul 16, 2012, at 8:11 AM, -Hammer- wrote:

> There are multiple issues here. I understand most folks on these threads are 
> beyond me but I'm pretty sure I'm not the only person in this position.
> 
> 1) (This one is currently a personal issue) I am still building up a true 
> IPv6 skillset. Yes, I understand it for the most part but now is the time to 
> apply it.

Frankly, IMHO, the best way to build up a truly useful IPv6 skill set is to 
start applying what you don't know and see what happens. For the most part, you 
will find that it is truly "96 more bits, no magic".

> 2) All the reading you do doesn't prepare you for application and the vendors 
> aren't necessarily helping. Feature parity across platforms and vendors 
> beyond just "interface x/x/x" and "ipv6 address fe80:blah:blah::babe:1" seems 
> to seriously be lacking. When I try to take what I understand and apply it 
> beyond the basics I often see hurdles.  Example? HSRP IPv6 global addressing 
> on Cisco ASR platform. If it's working for you hit me offline. Example2? Any 
> vendor product beyond a router or switch. CheckPoint FW? F5 LB? Netscaler LB 
> or AF? The WAN guys may be rolling deep in IPv6 but not everyone else. I just 
> got an EA this morning from CheckPoint for NAT66. This should have been ready 
> for prime time years ago. I guess the vendors weren't getting the push from 
> the customers so there was no need to make an effort

You probably meant 2001:db8:b1aa:b1aa::babe:1 ;-) (blah isn't hex and fe80::/10 
is link local. 2001:db8::/16 is the example prefix)

For the most part, HSRP really isn't even necessary or useful in IPv6 since ND 
should take care of what HSRP did for IPv4.

I believe F5 has rolled out IPv6 in a subset of their products and that you 
need pretty recent versions to get IPv6 functionality from them. The ARIN Wiki 
(http://www.getipv6.info) may be a good source of information on various vendor 
statuses. Contribute what you know/find out there as well, please.

Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able 
to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It 
has no good use in IPv6.

> 3) When I'm not preoccupied attempting to digest the fundamentals I am well 
> aware of the retooling of the brain that is required for this in a network 
> design. Last year I reached out to Team Cymru and attempted to build an IPv6 
> router template to match their IPv4 template. It was a completely different 
> animal. Ironically most of the STIGs and NSA reference garbage I used was ten 
> years old but still applied. After going thru all those docs my brain hurt 
> trying to orient my ACLs properly and go thru all the different attributes 
> you want to block where and when. Then I spent some time trying to work our 
> design schemas for our ARIN space with the WAN design team. What I'm trying 
> to say is that Roberts comments are spot on. It is a very different way of 
> thinking on a small scale and a large scale and you can't take your IPv4 
> logic and apply it. I've tried and it's just slowing me down.

Yes and no. If you have been doing IPv4 long enough to remember pre-NAT IPv4, 
then, you just need to remember some of the old ways of IPv4. If you have no 
recollection of IPv4 without NAT, then, you are correct, it is a huge paradigm 
shift to go back to the way the internet is supposed to have been before we ran 
out of addresses.

Owen

> 
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> On 7/15/2012 10:35 PM, Lee wrote:
>> On 7/14/12, Robert E. Seastrom  wrote:
>>> Actually, that's one of the most insightful meta-points I've seen on
>>> NANOG in a long time.
>>> 
>>> There is a HUGE difference between IPv4 and IPv6 thinking.  We've all
>>> been living in an austerity regime for so long that we've completely
>>> forgotten how to leave parsimony behind.  Even those of us who worked
>>> at companies that were summarily handed a Class B when we mumbled
>>> something about "internal subnetting" have a really hard time
>>> remembering how to act when we suddenly don't have to answer for every
>>> single host address and can design a network to conserve other things
>>> (like our brain cells).
>> Suggestions?
>> 
>> I feel like I should be able to do something really nice with an
>> absurdly large address space.  But lack of imagination or whatever.. I
>> haven't come up with anything that really appeals to me.
>> 
>> Thanks,
>> Lee
>> 
>> 
>>> -Hammer-  writes:
>>> 
 
 
 Thank you all. It's not the protocol that hurts. It's rethinking the
 culture/philosophy around it.
 
 -Hammer-
 
 On 7/14/12 3:20 PM, "Owen DeLong"  wrote:
 
> They're a bad thing in IPv6.
> 
> The only place for security through obscurity IMHO is a small round
> container that sits next to my desk.
> 
> Besides, if you don't advertise it, a GUA prefix is just as obscure as a
> ULA prefix and pro

Re: IPv6 Toolkit v1.2: Latest snapshot, and git repo

[Randy Carpenter]

Appears to compile file on Mac OS X 10.7. The resulting programs run, but I 
have not tried any real testing with actual data.


thanks,
-Randy


- Original Message -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Folks,
> 
> I've posted a snapshot (tarball) of my working copy of the IPv6
> toolkit. The tarball is available at:
> 
> 
> Additionally, I've created a git repository for the toolkit, such
> that
> collaboration is improved. The git repo is available at:
> 
> 
> If you have access to a Mac OS box, please try to compile the tools,
> and let me know if you find any errors (or let me know if they
> compiled cleanly). If you can also run the tools according to some of
> the examples in the manuals (and report any problems), that would be
> great, too.
> 
> P.S.: If you've sent patches and your patches have not yet been
> applied, most likely it just means that I'm catching-up with them
> (feel free to resend!).
> 
> Thanks!
> 
> Best regards,--
> Fernando Gont
> e-mail: ferna...@gont.com.ar || fg...@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJQAtn3AAoJEJbuqe/Qdv/xYIgH+wTQXJ3iNEnGnA0cMazS32py
> 3HfTdcMaEphnfF2a15dq1h/uqF05g3t9KqU744A1XmMtDlChvQ2I77uj2amqaeKi
> dED6e/NTuVAxTAI0ZTPIEn7BkDgtqvhuaoth+E4SX73lJC9eJR7e3T3BAtbESZaQ
> Sp67lvtgYmqogDc0IQALGNucyhHmacfUBocVLVgmVPn8BwdFxHI80W+Vc6TnKfjm
> Yc9ijgUPLTu0hOGD4bpOeQ2V3Dzw9PW17PyJlPr3TzWLzb8g64/zZROtHjXl/V4s
> 0JNAZVrHNDvA7kfEujzsoLcnQLCfq3+jzecvXcGwgsYMDXRBL8Lv628OAhrVglY=
> =Z3+1
> -END PGP SIGNATURE-
> 
> 
> 

Re: using "reserved" IPv6 space

[-Hammer-]

There are multiple issues here. I understand most folks on these threads 
are beyond me but I'm pretty sure I'm not the only person in this position.


1) (This one is currently a personal issue) I am still building up a 
true IPv6 skillset. Yes, I understand it for the most part but now is 
the time to apply it.


2) All the reading you do doesn't prepare you for application and the 
vendors aren't necessarily helping. Feature parity across platforms and 
vendors beyond just "interface x/x/x" and "ipv6 address 
fe80:blah:blah::babe:1" seems to seriously be lacking. When I try to 
take what I understand and apply it beyond the basics I often see 
hurdles.  Example? HSRP IPv6 global addressing on Cisco ASR platform. If 
it's working for you hit me offline. Example2? Any vendor product beyond 
a router or switch. CheckPoint FW? F5 LB? Netscaler LB or AF? The WAN 
guys may be rolling deep in IPv6 but not everyone else. I just got an EA 
this morning from CheckPoint for NAT66. This should have been ready for 
prime time years ago. I guess the vendors weren't getting the push from 
the customers so there was no need to make an effort


3) When I'm not preoccupied attempting to digest the fundamentals I am 
well aware of the retooling of the brain that is required for this in a 
network design. Last year I reached out to Team Cymru and attempted to 
build an IPv6 router template to match their IPv4 template. It was a 
completely different animal. Ironically most of the STIGs and NSA 
reference garbage I used was ten years old but still applied. After 
going thru all those docs my brain hurt trying to orient my ACLs 
properly and go thru all the different attributes you want to block 
where and when. Then I spent some time trying to work our design schemas 
for our ARIN space with the WAN design team. What I'm trying to say is 
that Roberts comments are spot on. It is a very different way of 
thinking on a small scale and a large scale and you can't take your IPv4 
logic and apply it. I've tried and it's just slowing me down.



-Hammer-

"I was a normal American nerd"
-Jack Herer

On 7/15/2012 10:35 PM, Lee wrote:

On 7/14/12, Robert E. Seastrom  wrote:

Actually, that's one of the most insightful meta-points I've seen on
NANOG in a long time.

There is a HUGE difference between IPv4 and IPv6 thinking.  We've all
been living in an austerity regime for so long that we've completely
forgotten how to leave parsimony behind.  Even those of us who worked
at companies that were summarily handed a Class B when we mumbled
something about "internal subnetting" have a really hard time
remembering how to act when we suddenly don't have to answer for every
single host address and can design a network to conserve other things
(like our brain cells).

Suggestions?

I feel like I should be able to do something really nice with an
absurdly large address space.  But lack of imagination or whatever.. I
haven't come up with anything that really appeals to me.

Thanks,
Lee



-Hammer-  writes:




Thank you all. It's not the protocol that hurts. It's rethinking the
culture/philosophy around it.

-Hammer-

On 7/14/12 3:20 PM, "Owen DeLong"  wrote:


They're a bad thing in IPv6.

The only place for security through obscurity IMHO is a small round
container that sits next to my desk.

Besides, if you don't advertise it, a GUA prefix is just as obscure as a
ULA prefix and provides a larger search space in which one has to hunt
for it... Think /3 instead of /8.

Owen

On Jul 14, 2012, at 1:14 PM, -Hammer- wrote:


Guys,
The whole purpose of this is that they do NOT need to be global.
Security thru obscurity. It actually has a place in some worlds. Does
that
make sense? Or are such V4-centric approaches a bad thing in v6?

On 7/13/12 8:41 PM, "Brandon Ross"  wrote:


On Fri, 13 Jul 2012, Owen DeLong wrote:


On Jul 13, 2012, at 4:24 PM, Randy Bush wrote:


keep life simple.  use global ipv6 space.

randy

Though it is rare, this is one time when I absolutely agree with
Randy.

It's even more rare for me to agree with Randy AND Owen at the same
time.

--
Brandon Ross  Yahoo & AIM:
BrandonNRoss
+1-404-635-6667ICQ:
2269442
Schedule a meeting:  https://tungle.me/bross Skype:
brandonross

Re: Netsol AAAA glue

[Joe Abley]

On 2012-07-14, at 02:06, Doug McIntyre wrote:

> OpenSRS does (now) have online IPv6 glue-record editing. 
> 
> They can insert DS records by hand if you email into their support
> department (assuming you are the reseller and you have access to their
> support department, otherwise you have to work through your reseller). 

For COM and NET only. Not ORG, not any ccTLDs, as far as I know.


Joe