Re: IPv6 end user addressing

[Mark Newton]

On 12/08/2011, at 7:23 AM, Scott Helms wrote:

> The question I asked you is why should I as the service provider deploy 
> routers rather than bridges as CPE gear for residential customers. 

As a service provider, you don't want to burn an expensive TCAM slot to make
IPv6 ND work for every device a customer places on their LAN.

As a service provider, it's better to burn one TCAM slot per customer for the
prefix you route to them, and leave adjacency relationships within their home
to them.

Think of MAC address table size limits on switches.  Similar problem.

  - mark


--
Mark Newton   Email:  new...@internode.com.au (W)
Network Engineer  Email:  new...@atdot.dotat.org  (H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: OSPF vs IS-IS

[Joel Jaeggli]

On Aug 11, 2011, at 3:19 PM, Randy Bush wrote:

>> The only reason in my opinion to run IS-IS rather than OSPF today is
>> due to the fact that IS-IS is decoupled from IP making it less
>> vulnerable to attacks.
> 
> how about simpler and more stable?

not rooted to a particular area.

supports more than one AFI at the same time

isn't dependent on ip addressing to form an adjacency

etc

> randy
> 

Re: OSPF vs IS-IS

[Stefan Fouant]

On 8/11/2011 8:16 PM, Jimmy Hess wrote:


I would encourage you to ask the opposite question:  " Is there any
reason to run OSPF over IS-IS in the SP core?"
And the answer would be...  probably not.  There is not really a good
technical reason to run OSPF over IS-IS in the SP core.
You might have some aesthetic considerations such as wanting the SP
core to run the same protocol as something else,
despite its limitations.


Just to add to everything that Jimmy said, if you've got the time to do 
an in-depth side-by-side analysis of the two protocols, I strongly 
recommend the book "OSPF and IS-IS: Choosing an IGP for Large-Scale 
Networks" by Jeff Doyle.  I can't speak highly enough of this book...


Stefan Fouant
JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

Re: Experience with Juniper MX-80s

[Bill Blackford]

I'm probably way off here, but: Imagine an MX with a single RE, 1
MX-MPC2-3D-Q that can be populated with your choice of MICs in FPC-1
and 1 MIC-3D-4XGE-XFP in FPC-0. But, they run a little hot.

-b



On Thu, Aug 11, 2011 at 3:59 PM, Brian Keefer  wrote:
> On Aug 11, 2011, at 6:43 AM, Babak Pasdar wrote:
>
>> Hello NANOG Group,
>>
>> I am curious if anyone has any experiences positive or negative with Juniper 
>> MX-80s.  Our recent experience with Juniper has not been great both in terms 
>> of new product offerings (SRX) and software bugs in the recent revs of Junos 
>> for the MX platform.  I want to know if the MX-80 functions as advertised 
>> and in specific can properly handle two full IPv4 and IPv6 BGP feeds
>
>
> I'm curious about these too.  Specifically, does anyone have 
> experience/thoughts on the anti-DDoS features?  I know there are scenarios it 
> wouldn't begin to address, but are they worth spending time to fiddle with?  
> Also, is anyone taking JFlow off of them?  We're trying to figure out how 
> much we could sample while doing about 900Mbps.  I'm not sure what our PPS 
> looks like off the top of my head.
>
> TIA.
>
> --
> chort
>
>
>



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.

Re: IPv6 end user addressing

[Cameron Byrne]

On Aug 11, 2011 5:25 PM, "Owen DeLong"  wrote:
>
>
> On Aug 11, 2011, at 5:08 PM, Matthew Moyle-Croft wrote:
>
> >
> > On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
> >
> >>
> >> On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
> >>
> >>>
> >>> On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
> 
>  I suppose that limiting enough households to too small an allocation
>  will have that effect. I would rather we steer the internet
deployment
>  towards liberal enough allocations to avoid such disability for the
>  future.
> >>>
> >>>
> >>> I see the lack of agreement on whether /48 or /56 or /60 is good for a
> >>> home network to be a positive thing.
> >>>
> >>> As long as there's no firm consensus, router vendors will have to
implement
> >>> features which don't make silly hard-coded assumptions.
> >>>
> >> Yes and no. In terms of potential innovations, if enough of the market
chooses
> >> /60, they will hard code the assumption that they cannot count on more
than
> >> a /60 being available into their development process regardless of what
> >> gets into the router. Sure, they won't be able to assume you can't get
a /48,
> >> but, they also won't necessarily implement features that would take
advantage
> >> of a /48.
> >
> >
> > Abundance doesn't drive innovations.  Scarcity does.  IPv6 does not have
a scarcity issue.  I assert that IPv6 addressing is not going to now or ever
do anything particularly innovative that can't be done better at other, more
relevant, layers.
> >
>
> Abundance won't drive innovation, but, scarcity can block it.
>
> If enough providers limit their residential customers to /60s, then, that
will become the defining limit to which vendors implement.
>
> > The time for arguing about arbitrary things that make no difference to
the end customers has passed.  The navel gazing must cease and we must move
forward on IPv6 to the home rather than continuing the confusion about this
and other IPv6 arbitrary bit obsession stuff.
> >
>
> On that I believe we are in complete agreement. Let's deploy IPv6 to end
users and give them /48s and move on.
>
> > We need to stop spending our time on rearranging the Titanic's
deckchairs and get the  on with stopping the crashing into the
iceberg by providing clear leadership on getting IPv6 to the masses to
enable their APPLICATIONS and EXPERIENCE without the impending doom of IPv4
CGN.
> >
>
> Again, no argument.
>
> > My name is Matthew, I HAVE given my customers the ability to get IPv6
and I don't give a flying one about the prefix length, I care about getting
ANY prefix to the end users so they can use it and solve the issues at their
end.  I AM enabling innovation just by doing that.
> >
>
> My name is Owen. I work for an ISP that gives IPv6 to our customers and
anyone else who cares to connect.
>
> We care about prefix length because we believe it will impact innovation
for many years.
>
> Yes, getting something to end users is more important than how big of a
prefix we give them. On that, MMC and I are in complete agreement.
>
> However, there are choices to be made in how we do it and giving out /48s
costs virtually nothing and yields real potential benefits. There
> is no meaningful advantage to placing arbitrary limits below /48 on
residential customers.
>

I agree that this debate  is confusing people and will not be solved here.
Let's move on to a more productive topic. There is more than one way to
deploy ipv6. Do what's right for your own users and network.

Cb
> Owen
>
>

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 11, 2011, at 5:08 PM, Matthew Moyle-Croft wrote:

> 
> On 11/08/2011, at 1:33 PM, Owen DeLong wrote:
> 
>> 
>> On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
>> 
>>> 
>>> On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
 
 I suppose that limiting enough households to too small an allocation
 will have that effect. I would rather we steer the internet deployment
 towards liberal enough allocations to avoid such disability for the
 future.
>>> 
>>> 
>>> I see the lack of agreement on whether /48 or /56 or /60 is good for a
>>> home network to be a positive thing.
>>> 
>>> As long as there's no firm consensus, router vendors will have to implement
>>> features which don't make silly hard-coded assumptions.
>>> 
>> Yes and no. In terms of potential innovations, if enough of the market 
>> chooses
>> /60, they will hard code the assumption that they cannot count on more than
>> a /60 being available into their development process regardless of what
>> gets into the router. Sure, they won't be able to assume you can't get a /48,
>> but, they also won't necessarily implement features that would take advantage
>> of a /48.
> 
> 
> Abundance doesn't drive innovations.  Scarcity does.  IPv6 does not have a 
> scarcity issue.  I assert that IPv6 addressing is not going to now or ever do 
> anything particularly innovative that can't be done better at other, more 
> relevant, layers.  
> 

Abundance won't drive innovation, but, scarcity can block it.

If enough providers limit their residential customers to /60s, then, that will 
become the defining limit to which vendors implement.

> The time for arguing about arbitrary things that make no difference to the 
> end customers has passed.  The navel gazing must cease and we must move 
> forward on IPv6 to the home rather than continuing the confusion about this 
> and other IPv6 arbitrary bit obsession stuff.
> 

On that I believe we are in complete agreement. Let's deploy IPv6 to end users 
and give them /48s and move on.

> We need to stop spending our time on rearranging the Titanic's deckchairs and 
> get the  on with stopping the crashing into the iceberg by 
> providing clear leadership on getting IPv6 to the masses to enable their 
> APPLICATIONS and EXPERIENCE without the impending doom of IPv4 CGN.
> 

Again, no argument.

> My name is Matthew, I HAVE given my customers the ability to get IPv6 and I 
> don't give a flying one about the prefix length, I care about getting ANY 
> prefix to the end users so they can use it and solve the issues at their end. 
>  I AM enabling innovation just by doing that.  
> 

My name is Owen. I work for an ISP that gives IPv6 to our customers and anyone 
else who cares to connect.

We care about prefix length because we believe it will impact innovation for 
many years.

Yes, getting something to end users is more important than how big of a prefix 
we give them. On that, MMC and I are in complete agreement.

However, there are choices to be made in how we do it and giving out /48s costs 
virtually nothing and yields real potential benefits. There
is no meaningful advantage to placing arbitrary limits below /48 on residential 
customers.

Owen

Re: OSPF vs IS-IS

[Jimmy Hess]

On Thu, Aug 11, 2011 at 5:19 PM, Randy Bush  wrote:
> how about simpler and more stable?

ISIS is also decoupled from  IP making it more robust and
flexible/future-proof, as in adaptible to
new protocols  --   IP connectivity is not required for ISIS nodes  to
discover and associate with
L2 connected neighbors.   At the fundamental level, there are plenty
of reasons to exclude
OSPF from running  in a SP core;  when a technically superior choice
is available and usable.

The  IP decoupling is a good example.
As in, ISIS topology is independent from (non-tunneled) IP topology,
which is more flexible.
There is less complexity, and basic troubleshooting is facilitated
favorably to OSPFv2/v3, due
to the larger amount of baggage OSPF carries with it.

If you need to renumber your network, including IS-IS routers',  you
will  impact  the contents
of  IPv4 routes transmitted and forwarding table contents,
but your adjacencies  do not rely on the IP protocol, and aren't
dependant on neighbor IP addressing.

Need to support IPv6 addresses?   ISIS was trivially extended to do it.
Need to support routing to MAC addresses?  Again... just a new type field.

OSPF requires... shall we say,  more fundamental changes to attempt to
extend it.
More fundamental changes to a more complex protocol = more
opportunities for bugs.



I would encourage you to ask the opposite question:  " Is there any
reason to run OSPF over IS-IS in the SP core?"
And the answer would be...  probably not.  There is not really a good
technical reason to run OSPF over IS-IS in the SP core.
You might have some aesthetic considerations such as wanting the SP
core to run the same protocol as something else,
despite its limitations.

Then you will have to ask yourself if the aesthetic considerations
outweigh the technical benefits.

--
-JH

Re: IPv6 end user addressing

[Matthew Moyle-Croft]

On 11/08/2011, at 1:33 PM, Owen DeLong wrote:

> 
> On Aug 10, 2011, at 7:45 PM, Mark Newton wrote:
> 
>> 
>> On 11/08/2011, at 8:42 AM, Owen DeLong wrote:
>>> 
>>> I suppose that limiting enough households to too small an allocation
>>> will have that effect. I would rather we steer the internet deployment
>>> towards liberal enough allocations to avoid such disability for the
>>> future.
>> 
>> 
>> I see the lack of agreement on whether /48 or /56 or /60 is good for a
>> home network to be a positive thing.
>> 
>> As long as there's no firm consensus, router vendors will have to implement
>> features which don't make silly hard-coded assumptions.
>> 
> Yes and no. In terms of potential innovations, if enough of the market chooses
> /60, they will hard code the assumption that they cannot count on more than
> a /60 being available into their development process regardless of what
> gets into the router. Sure, they won't be able to assume you can't get a /48,
> but, they also won't necessarily implement features that would take advantage
> of a /48.


Abundance doesn't drive innovations.  Scarcity does.  IPv6 does not have a 
scarcity issue.  I assert that IPv6 addressing is not going to now or ever do 
anything particularly innovative that can't be done better at other, more 
relevant, layers.  

The time for arguing about arbitrary things that make no difference to the end 
customers has passed.  The navel gazing must cease and we must move forward on 
IPv6 to the home rather than continuing the confusion about this and other IPv6 
arbitrary bit obsession stuff.

We need to stop spending our time on rearranging the Titanic's deckchairs and 
get the  on with stopping the crashing into the iceberg by providing 
clear leadership on getting IPv6 to the masses to enable their APPLICATIONS and 
EXPERIENCE without the impending doom of IPv4 CGN.

My name is Matthew, I HAVE given my customers the ability to get IPv6 and I 
don't give a flying one about the prefix length, I care about getting ANY 
prefix to the end users so they can use it and solve the issues at their end.  
I AM enabling innovation just by doing that.  

MMC

Re: [BULK] Re: SORBS contact

[Valdis . Kletnieks]

On Thu, 28 Jul 2011 16:17:02 CDT, trinity.edu's mailer, *not* "Brian R. 
Watters" said:

> Sender: brwatt...@absfoc.com
> Subject: Re: [BULK]  Re: SORBS contact
> Message-Id: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office>
> Recipient: ge...@trinity.edu.test-google-a.com, Forwarded: 
> gerno.rein...@trinity.edu

WIll somebody please smack the trinity.edu mail system upside the head?

And then smack whatever deluded code hacker that couldn't be bothered to DTRT
and cloned the inbound RFC822 headers into the outbound ones rather than
generating an appropriate DSN? RFC1894 was back in 1996, there's no excuse this
far into this century to botch this.



pgpzdO0YOWdCH.pgp
Description: PGP signature

Re: [BULK] Re: SORBS contact

[Brian R. Watters]

Sender: brwatt...@absfoc.com
Subject: Re: [BULK]  Re: SORBS contact
Message-Id: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office>
Recipient: ge...@trinity.edu.test-google-a.com, Forwarded: 
gerno.rein...@trinity.edu
--- Begin Message ---
Thanks .. their attempts to reach us are blocked via our Barrcacuda's due to 
the fact that they are sending with a blank FROM: and as such Barracuda thinks 
its SPAM .. just to darn funny .. I have whitelisted their domain so on my 
fourth attempt we will see .. Cant create tickets or communicate with them 
unless you have an account and you can not get an active account unless you can 
get an email to activate it .. very frustrating to say the least. 



- Original Message -

From: "Dorn Hetzel"  
To: "William Pitcock"  
Cc: "Brian R. Watters" , nanog@nanog.org 
Sent: Thursday, July 28, 2011 12:47:56 PM 
Subject: [BULK] Re: SORBS contact 

You want to speak to SORBS? Good luck with that. Unless you are Chuck Norris; 
Chuck Norris can speak with SORBS anytime he wants :) 


On Thu, Jul 28, 2011 at 3:50 PM, William Pitcock < neno...@systeminplace.net > 
wrote: 





On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) 
"Brian R. Watters" < brwatt...@absfoc.com > wrote: 

> We are looking for a SORBS contact as their web site and registration 
> process is less than friendly if somehow you get listed by them. 

As I recall it, you can manually create an account on their 
request-tracker instance and open a ticket through that requesting 
delisting... however, complaining on NANOG is probably just going to 
result in a less than friendly response from Michelle (at least as 
history as shown). 

William 





--- End Message ---

Re: SORBS contact

[Brian R. Watters]

Sender: brwatt...@absfoc.com
Subject: Re: SORBS contact
Message-Id: <8beae4f1-acd0-4408-9f75-264aff04d788@brw-abs-office>
Recipient: ge...@trinity.edu.test-google-a.com, Forwarded: 
gerno.rein...@trinity.edu
--- Begin Message ---
Nope .. just like pain and suffering :( 

- Original Message -

From: "Valdis Kletnieks"  
To: "Brian R. Watters"  
Cc: nanog@nanog.org 
Sent: Thursday, July 28, 2011 12:44:29 PM 
Subject: Re: SORBS contact 

On Thu, 28 Jul 2011 12:31:13 PDT, "Brian R. Watters" said: 
> We are looking for a SORBS contact as their web site and registration process 
> is less than friendly if somehow you get listed by them. 

You're new here, aren't you? :) 

(Sorry, couldn't resist. Previous discussion on NANOG: 

http://www.google.com/search?sourceid=mozclient&scoring=d&ie=utf-8&oe=utf-8&q=sorbs+site%3Ananog%2Eorg
 



--- End Message ---

Re: Experience with Juniper MX-80s

[Brian Keefer]

On Aug 11, 2011, at 6:43 AM, Babak Pasdar wrote:

> Hello NANOG Group,
> 
> I am curious if anyone has any experiences positive or negative with Juniper 
> MX-80s.  Our recent experience with Juniper has not been great both in terms 
> of new product offerings (SRX) and software bugs in the recent revs of Junos 
> for the MX platform.  I want to know if the MX-80 functions as advertised and 
> in specific can properly handle two full IPv4 and IPv6 BGP feeds 


I'm curious about these too.  Specifically, does anyone have 
experience/thoughts on the anti-DDoS features?  I know there are scenarios it 
wouldn't begin to address, but are they worth spending time to fiddle with?  
Also, is anyone taking JFlow off of them?  We're trying to figure out how much 
we could sample while doing about 900Mbps.  I'm not sure what our PPS looks 
like off the top of my head.

TIA.

--
chort

Re: OSPF vs IS-IS

[Stefan Fouant]

I'll go with that... And one other thing... Traditionally it has been easier 
for developers to add new features to IS-IS because of the structure and 
flexibility of TLVs, whereas OSPF required the design of entirely new LSA types 
to support similar capabilities... I guess this has become less of an issue 
over the last few years however...

Nonetheless, if I was building a greenfield network today, I would personally 
go with IS-IS, but that is largely because of my many years working with the 
protocol...

Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

Sent from my iPad

On Aug 11, 2011, at 6:19 PM, Randy Bush  wrote:

>> The only reason in my opinion to run IS-IS rather than OSPF today is
>> due to the fact that IS-IS is decoupled from IP making it less
>> vulnerable to attacks.
> 
> how about simpler and more stable?
> 
> randy

Re: network issue help

[Phil Pierotti]

Of course you forgot

ABCD : Activity Before Cogitation Disorder

Phil P

On Thu, Aug 11, 2011 at 11:12 PM, mikea  wrote:

> On Thu, Aug 11, 2011 at 10:39:59AM +1000, Matthew Palmer wrote:
> > On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote:
> > > Is there an acronym for RTFM when there are a volume of manuals that
> need to be read?
> >
> > FOAD, perhaps?
>
> Well, there's ADD: Attention Deficit Disorder.
> Then there's ADHD: Attendion Deficit Hyperactivity Disorder.
> And there's ADCD: Absent During Clue Distribution.
>
> I think #3 may fit best.
>
> --
> Mike Andrews, W5EGO
> mi...@mikea.ath.cx
> Tired old sysadmin
>
>


-- 
 two eyes to tease, an aargh ... an oh there's a pie in there somewhere
<

Re: Experience with Juniper MX-80s

[Randy Bush]

> I am curious if anyone has any experiences positive or negative with
> Juniper MX-80s.

they seem to work

> Our recent experience with Juniper has not been great both in terms of
> new product offerings (SRX) and software bugs in the recent revs of
> Junos for the MX platform.

yes, juniper has become a router vendor of sufficient scale to have all
the good and the bad.  such is life.

> I want to know if the MX-80 functions as advertised and in specific
> can properly handle two full IPv4 and IPv6 BGP feeds

easily

randy

Re: OSPF vs IS-IS

[Randy Bush]

> The only reason in my opinion to run IS-IS rather than OSPF today is
> due to the fact that IS-IS is decoupled from IP making it less
> vulnerable to attacks.

how about simpler and more stable?

randy

Re: IPv6 end user addressing

[Greg Ihnen]

On Aug 11, 2011, at 5:05 PM, Owen DeLong wrote:

>> 
>> I respectfully disagree. If appliance manufacturers jump on the bandwagon to 
>> make their device *Internet Ready!* we'll see appliance makers who have way 
>> less networking experience than Linksys/Cisco getting into the fray. I 
>> highly doubt the pontifications of these Good Morning America technology 
>> gurus who predict all these changes are coming to the home. Do we really 
>> think appliance manufacturers are going to agree on standards for keeping 
>> track of how much milk is in the fridge, especially as not just 
>> manufacturing but also engineering is moving to countries like China? How 
>> about the predictions that have been around for years about appliances which 
>> will alert the manufacturer about impending failure so they can call you and 
>> you can schedule the repair before there's a breakdown? Remember that one? 
>> We don't even have an "appliance about to break, call repairman" idiot light 
>> on appliances yet.
>> 
> What standards?  The RFID tag on the milk carton will, essentially, replace 
> the bar code once RFID tags become cheap enough. It'll be like an 
> uber-barcode with a bunch more information.
> 
> For keeping track of how much, cheap sensitive pressure transducers will know 
> by the position of the RFID tag combined with the weight of the thing at that 
> location in the refrigerator. There's no new standard required.
> 
> The technology to do this exists today. The integration and mainstream 
> acceptance is still years, if not decades off, but, IPv6 should last for 
> decades, so, if we don't plan for at least the things we can see coming today 
> and already know feasible ways to implement, we're doomed for the other 
> unexpected things we don't see coming.
> 

What reads the RFID's and the pressure sensors? What server or application 
receives this data and deals with it according to the user's desires? How does 
that data or the information and alerts this system would generate get to the 
user's devices? There has to be a device in the home or a server somewhere for 
a service the home owner subscribes to which keeps an inventory of all these 
things and acts on it. 

Do you really think it's going to be common place for people to have this kind 
of technology and more importantly use it?

I think the kitchen you foresee is the kind of dream kitchen the kind of people 
who imbed RFID chips in themselves so they can have a house that opens the 
doors and turns on the lights as they approach.

You don't have a chip in you, do you?


>> But I predict the coming of IPv6 to the home in a big way will have 
>> unintended consequences.
>> 
> 
> Definitely.
> 
> 
>> I think the big shock for home users regarding IPv6 will be suddenly having 
>> their IPv4 NAT firewall being gone and all their devices being exposed naked 
>> to everyone on the internet. Suddenly all their security shortcomings (no 
>> passwords, "password" for the password etc) are going to have catastrophic 
>> consequences. I foresee an exponential leap in the  number of hacks of 
>> consumer devices which will have repercussions well beyond their local 
>> network. In my opinion that's going to be the biggest problem with IPv6, not 
>> all the concerns about the inner workings of the protocols. I'm guessing the 
>> manufacturers of consumer grade networkable devices are still thinking about 
>> security as it applies to LANs with rfc 1918 address space behind a firewall 
>> and haven't rethought security as it applies to IPv6.
>> 
> 
> Sigh... 
> 
> Continuing to propagate this myth doesn't make it any more true than it was 
> 10 years ago.

I'm sorry, what was the myth there? The public overall uses bad passwords and 
knowingly does not comply with security best practices? More connectivity is 
going to bring more problems and exploits? Those myths?

> 
> NAT != Security
> End-to-End addressing != End-to-End connectivity
> It will not be long before the average residential IPv6 gateway comes with a 
> default deny all inbound stateful firewall built in. Once you have that, your 
> hosts are not exposed naked to everyone on the internet. In fact, they are no 
> more exposed than with NAT with the key difference being that if you choose 
> to expose one or more hosts, you have the option of deliberately doing so.

We'll see.

> 
> Actually, I know for certain that most of the CPE manufacturers are 
> participating in the effort to draft better security requirements for 
> residential gateways as a current ID and hopefully an RFC soon. I believe, as 
> a matter of fact, that this is a BIS document being intended as a more 
> comprehensive improvement over the initial version.
> 
> Owen
> 

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 11, 2011, at 2:53 PM, Scott Helms wrote:

> On 8/11/2011 5:28 PM, Owen DeLong wrote:
>> You're talking about the front end residential gateway that you manage. I'm 
>> talking about
>> the various gateways and things you might not yet expect to provide gateways 
>> that residential
>> end users will deploy on their own within their environments.
> 
> The question I asked you is why should I as the service provider deploy 
> routers rather than bridges as CPE gear for residential customers.  If you 
> didn't understand the question or didn't want to address that specific 
> questions that's fine, but you certainly didn't answer that question.
> 

I think i did below. However, in my region of the world, most service providers 
don't provide the
CPE and most customers are BYOB.

>> Of course, in order for the ISP to properly support these things in the 
>> home, the ISP
>> needs to terminate some form of IPv6 on some form of CPE head-end router in 
>> the
>> home to which he will (statically or otherwise) route the /48 whether it is 
>> statically
>> assigned or configured via DHCPv6-PD.
> 
> What is a CPE head-end router?  That seems like an oxymoron.  Where would 
> such an animal live, in the home or the head end/central office?  Who is 
> responsible for purchasing it and managing it in your mind?
> 

In the home and the consumer is responsible. The fact that you utterly want to 
avoid
the concept of topology in the home shows me that you really aren't 
understanding
where things already are in many homes and where they are going in the future.

ISP->CPE Head End Router->> 
>> Owen
>> 
>> On Aug 11, 2011, at 1:28 PM, Scott Helms wrote:
>> 
>>> Owen,
>>> 
>>>The fact that you're immediately going to routing means you don't 
>>> understand the problem.  The costs I'm talking about don't have anything to 
>>> do with routing or any of the core gear and everything to do with the 
>>> pieces at the customer premise.  Routers cost more to purchase than bridges 
>>> because there is more complexity (silicon&  software).  Routers also cost 
>>> more to manage for a service provider in almost all cases for residential 
>>> customers.  There are reasons to deploy routing CPE in some cases (the use 
>>> cases are increasing with IP video in DOCSIS systems) but they are still 
>>> very nascent.
>>> 
>>> On 8/10/2011 7:24 PM, Owen DeLong wrote:
 I'm pretty sure that I understand those things reasonably well. I'm quite 
 certain that it doesn't
 cost an ISP significantly more to deploy /48s than /56s as addresses don't 
 have much of a
 cost and there is little or no difficulty in obtaining large allocations 
 for ISPs that have lots of
 residential users. The difference between handing a user's CPE a /56 and a 
 /48 will not make
 for significant difference in support costs, either, other than the 
 possible additional costs of
 the phone calls when users start to discover that /56s were not enough.
 
 
 Owen
 
 On Aug 10, 2011, at 11:43 AM, Scott Helms wrote:
 
> Tim,
> 
>Hence the "might".  I worry when people start throwing around terms 
> like routing in the home that they don't understand the complexities of 
> balancing the massive CPE installed base, technical features, end user 
> support, ease of installation&   managemenet, and (perhaps most 
> importantly) the economics of mass adoption.  This one of the choices 
> that made DSL deployments more complex and expensive than DOCSIS cable 
> deployments which in turn caused the CEO of AT&T to say their entire DSL 
> network is obsolete.
> http://goo.gl/exwqu
> 
> 
> 
> On 8/10/2011 12:57 PM, Tim Chown wrote:
>> On 10 Aug 2011, at 16:11, Scott Helms wrote:
>> 
>>> Neither of these are true, though in the future we _might_ have 
>>> deployable technology that allows for automated routing setup (though I 
>>> very seriously doubt it) in the home.  Layer 2 isolation is both easier 
>>> and more reliable than attempting it at layer 3 which is isolation by 
>>> agreement, i.e. it doesn't really exist.
>> Well, there is some new effort on this in the homenet WG in IETF.
>> 
>> For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use 
>> it in our enterprise since we have multiple multicast video channels in 
>> use.
>> 
>> Tim
>> 
>>> On 8/10/2011 9:02 AM, Owen DeLong wrote:
 Bridging eliminates the multicast isolation that you get from routing.
 
 This is not a case for bridging, it's a case for making it possible to 
 do real
 routing in the home and we now have the space and the technology to
 actually do it in a meaningful and sufficiently automatic way as to be
 applicable to Joe 6-Mac.
 
>>> -- 
>>> Scott Helms
>>> Vice President of Technology
>>> ISP Alliance, Inc

Re: IPv6 end user addressing

[Brian E Carpenter]

Eugen,

On 2011-08-11 21:53, Eugen Leitl wrote:
> On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote:
> 
>> Well, we know that the human population will stabilise somewhere below
>> ten billion by around 2050. The current unicast space provides for about
> 
> How about the machine population? How about self-replicating systems?

I think considering the size of such systems as a function of
the size of the human population is quite reasonable, in terms
of thinking about natural and economic limits to growth.

> How about geography-based address allocation, to go away with global routing
> tables? 

That is a whole discussion in itself, but in any case it surely
won't be part of 2000::/3. Additionally, the number of prefixes
needed for any reasonable geographic scheme is quite trivial
compared to the trillions available.

> How about InterPlaNet, such as LEO routers, solar power
> satellites, controlling industrial production on the Moon and elsewhere?

Probably also trivial numbers compared to 15 trillion /48s,
but if not, again, we are not limited to 2000::/3 for ever.

EOF for me on this sub-topic.

   Brian

Re: IPv6 end user addressing

[Scott Helms]

On 8/11/2011 5:28 PM, Owen DeLong wrote:

You're talking about the front end residential gateway that you manage. I'm 
talking about
the various gateways and things you might not yet expect to provide gateways 
that residential
end users will deploy on their own within their environments.


The question I asked you is why should I as the service provider deploy 
routers rather than bridges as CPE gear for residential customers.  If 
you didn't understand the question or didn't want to address that 
specific questions that's fine, but you certainly didn't answer that 
question.



Of course, in order for the ISP to properly support these things in the home, 
the ISP
needs to terminate some form of IPv6 on some form of CPE head-end router in the
home to which he will (statically or otherwise) route the /48 whether it is 
statically
assigned or configured via DHCPv6-PD.


What is a CPE head-end router?  That seems like an oxymoron.  Where 
would such an animal live, in the home or the head end/central office?  
Who is responsible for purchasing it and managing it in your mind?




Owen

On Aug 11, 2011, at 1:28 PM, Scott Helms wrote:


Owen,

The fact that you're immediately going to routing means you don't understand 
the problem.  The costs I'm talking about don't have anything to do with routing or 
any of the core gear and everything to do with the pieces at the customer premise.  
Routers cost more to purchase than bridges because there is more complexity 
(silicon&  software).  Routers also cost more to manage for a service provider 
in almost all cases for residential customers.  There are reasons to deploy routing 
CPE in some cases (the use cases are increasing with IP video in DOCSIS systems) 
but they are still very nascent.

On 8/10/2011 7:24 PM, Owen DeLong wrote:

I'm pretty sure that I understand those things reasonably well. I'm quite 
certain that it doesn't
cost an ISP significantly more to deploy /48s than /56s as addresses don't have 
much of a
cost and there is little or no difficulty in obtaining large allocations for 
ISPs that have lots of
residential users. The difference between handing a user's CPE a /56 and a /48 
will not make
for significant difference in support costs, either, other than the possible 
additional costs of
the phone calls when users start to discover that /56s were not enough.


Owen

On Aug 10, 2011, at 11:43 AM, Scott Helms wrote:


Tim,

Hence the "might".  I worry when people start throwing around terms like routing in 
the home that they don't understand the complexities of balancing the massive CPE installed base, 
technical features, end user support, ease of installation&   managemenet, and (perhaps most 
importantly) the economics of mass adoption.  This one of the choices that made DSL deployments 
more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T 
to say their entire DSL network is obsolete.
http://goo.gl/exwqu



On 8/10/2011 12:57 PM, Tim Chown wrote:

On 10 Aug 2011, at 16:11, Scott Helms wrote:


Neither of these are true, though in the future we _might_ have deployable 
technology that allows for automated routing setup (though I very seriously 
doubt it) in the home.  Layer 2 isolation is both easier and more reliable than 
attempting it at layer 3 which is isolation by agreement, i.e. it doesn't 
really exist.

Well, there is some new effort on this in the homenet WG in IETF.

For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use it in 
our enterprise since we have multiple multicast video channels in use.

Tim


On 8/10/2011 9:02 AM, Owen DeLong wrote:

Bridging eliminates the multicast isolation that you get from routing.

This is not a case for bridging, it's a case for making it possible to do real
routing in the home and we now have the space and the technology to
actually do it in a meaningful and sufficiently automatic way as to be
applicable to Joe 6-Mac.


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

http://twitter.com/kscotthelms




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

http://twitter.com/kscotthelms




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

http://twitter.com/kscotthelms






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

http://twitter.com/kscotthelms

Re: IPv6 end user addressing

[Owen DeLong]

> 
> I respectfully disagree. If appliance manufacturers jump on the bandwagon to 
> make their device *Internet Ready!* we'll see appliance makers who have way 
> less networking experience than Linksys/Cisco getting into the fray. I highly 
> doubt the pontifications of these Good Morning America technology gurus who 
> predict all these changes are coming to the home. Do we really think 
> appliance manufacturers are going to agree on standards for keeping track of 
> how much milk is in the fridge, especially as not just manufacturing but also 
> engineering is moving to countries like China? How about the predictions that 
> have been around for years about appliances which will alert the manufacturer 
> about impending failure so they can call you and you can schedule the repair 
> before there's a breakdown? Remember that one? We don't even have an 
> "appliance about to break, call repairman" idiot light on appliances yet.
> 
What standards?  The RFID tag on the milk carton will, essentially, replace the 
bar code once RFID tags become cheap enough. It'll be like an uber-barcode with 
a bunch more information.

For keeping track of how much, cheap sensitive pressure transducers will know 
by the position of the RFID tag combined with the weight of the thing at that 
location in the refrigerator. There's no new standard required.

The technology to do this exists today. The integration and mainstream 
acceptance is still years, if not decades off, but, IPv6 should last for 
decades, so, if we don't plan for at least the things we can see coming today 
and already know feasible ways to implement, we're doomed for the other 
unexpected things we don't see coming.

> But I predict the coming of IPv6 to the home in a big way will have 
> unintended consequences.
> 

Definitely.


> I think the big shock for home users regarding IPv6 will be suddenly having 
> their IPv4 NAT firewall being gone and all their devices being exposed naked 
> to everyone on the internet. Suddenly all their security shortcomings (no 
> passwords, "password" for the password etc) are going to have catastrophic 
> consequences. I foresee an exponential leap in the  number of hacks of 
> consumer devices which will have repercussions well beyond their local 
> network. In my opinion that's going to be the biggest problem with IPv6, not 
> all the concerns about the inner workings of the protocols. I'm guessing the 
> manufacturers of consumer grade networkable devices are still thinking about 
> security as it applies to LANs with rfc 1918 address space behind a firewall 
> and haven't rethought security as it applies to IPv6.
> 

Sigh... 

Continuing to propagate this myth doesn't make it any more true than it was 10 
years ago.

NAT != Security
End-to-End addressing != End-to-End connectivity
It will not be long before the average residential IPv6 gateway comes with a 
default deny all inbound stateful firewall built in. Once you have that, your 
hosts are not exposed naked to everyone on the internet. In fact, they are no 
more exposed than with NAT with the key difference being that if you choose to 
expose one or more hosts, you have the option of deliberately doing so.

Actually, I know for certain that most of the CPE manufacturers are 
participating in the effort to draft better security requirements for 
residential gateways as a current ID and hopefully an RFC soon. I believe, as a 
matter of fact, that this is a BIS document being intended as a more 
comprehensive improvement over the initial version.

Owen

Re: IPv6 end user addressing

[Owen DeLong]

You're talking about the front end residential gateway that you manage. I'm 
talking about
the various gateways and things you might not yet expect to provide gateways 
that residential
end users will deploy on their own within their environments.

The fact that you are talking about an entirely different problem space than I 
am shows that
it is you who does not understand either the problem I am describing or the 
solution space
that is applicable.

Of course, in order for the ISP to properly support these things in the home, 
the ISP
needs to terminate some form of IPv6 on some form of CPE head-end router in the
home to which he will (statically or otherwise) route the /48 whether it is 
statically
assigned or configured via DHCPv6-PD.

Owen

On Aug 11, 2011, at 1:28 PM, Scott Helms wrote:

> Owen,
> 
>The fact that you're immediately going to routing means you don't 
> understand the problem.  The costs I'm talking about don't have anything to 
> do with routing or any of the core gear and everything to do with the pieces 
> at the customer premise.  Routers cost more to purchase than bridges because 
> there is more complexity (silicon & software).  Routers also cost more to 
> manage for a service provider in almost all cases for residential customers.  
> There are reasons to deploy routing CPE in some cases (the use cases are 
> increasing with IP video in DOCSIS systems) but they are still very nascent.
> 
> On 8/10/2011 7:24 PM, Owen DeLong wrote:
>> I'm pretty sure that I understand those things reasonably well. I'm quite 
>> certain that it doesn't
>> cost an ISP significantly more to deploy /48s than /56s as addresses don't 
>> have much of a
>> cost and there is little or no difficulty in obtaining large allocations for 
>> ISPs that have lots of
>> residential users. The difference between handing a user's CPE a /56 and a 
>> /48 will not make
>> for significant difference in support costs, either, other than the possible 
>> additional costs of
>> the phone calls when users start to discover that /56s were not enough.
>> 
>> 
>> Owen
>> 
>> On Aug 10, 2011, at 11:43 AM, Scott Helms wrote:
>> 
>>> Tim,
>>> 
>>>Hence the "might".  I worry when people start throwing around terms like 
>>> routing in the home that they don't understand the complexities of 
>>> balancing the massive CPE installed base, technical features, end user 
>>> support, ease of installation&  managemenet, and (perhaps most importantly) 
>>> the economics of mass adoption.  This one of the choices that made DSL 
>>> deployments more complex and expensive than DOCSIS cable deployments which 
>>> in turn caused the CEO of AT&T to say their entire DSL network is obsolete.
>>> http://goo.gl/exwqu
>>> 
>>> 
>>> 
>>> On 8/10/2011 12:57 PM, Tim Chown wrote:
 On 10 Aug 2011, at 16:11, Scott Helms wrote:
 
> Neither of these are true, though in the future we _might_ have 
> deployable technology that allows for automated routing setup (though I 
> very seriously doubt it) in the home.  Layer 2 isolation is both easier 
> and more reliable than attempting it at layer 3 which is isolation by 
> agreement, i.e. it doesn't really exist.
 Well, there is some new effort on this in the homenet WG in IETF.
 
 For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use it 
 in our enterprise since we have multiple multicast video channels in use.
 
 Tim
 
> On 8/10/2011 9:02 AM, Owen DeLong wrote:
>> Bridging eliminates the multicast isolation that you get from routing.
>> 
>> This is not a case for bridging, it's a case for making it possible to 
>> do real
>> routing in the home and we now have the space and the technology to
>> actually do it in a meaningful and sufficiently automatic way as to be
>> applicable to Joe 6-Mac.
>> 
> -- 
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> 
> http://twitter.com/kscotthelms
> 
> 
> 
>>> -- 
>>> Scott Helms
>>> Vice President of Technology
>>> ISP Alliance, Inc. DBA ZCorum
>>> (678) 507-5000
>>> 
>>> http://twitter.com/kscotthelms
>>> 
>>> 
> 
> 
> -- 
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> 
> http://twitter.com/kscotthelms
> 

Re: IPv6 end user addressing

[Scott Helms]

Owen,

The fact that you're immediately going to routing means you don't 
understand the problem.  The costs I'm talking about don't have anything 
to do with routing or any of the core gear and everything to do with the 
pieces at the customer premise.  Routers cost more to purchase than 
bridges because there is more complexity (silicon & software).  Routers 
also cost more to manage for a service provider in almost all cases for 
residential customers.  There are reasons to deploy routing CPE in some 
cases (the use cases are increasing with IP video in DOCSIS systems) but 
they are still very nascent.


On 8/10/2011 7:24 PM, Owen DeLong wrote:

I'm pretty sure that I understand those things reasonably well. I'm quite 
certain that it doesn't
cost an ISP significantly more to deploy /48s than /56s as addresses don't have 
much of a
cost and there is little or no difficulty in obtaining large allocations for 
ISPs that have lots of
residential users. The difference between handing a user's CPE a /56 and a /48 
will not make
for significant difference in support costs, either, other than the possible 
additional costs of
the phone calls when users start to discover that /56s were not enough.


Owen

On Aug 10, 2011, at 11:43 AM, Scott Helms wrote:


Tim,

Hence the "might".  I worry when people start throwing around terms like routing in 
the home that they don't understand the complexities of balancing the massive CPE installed base, 
technical features, end user support, ease of installation&  managemenet, and (perhaps most 
importantly) the economics of mass adoption.  This one of the choices that made DSL deployments 
more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T 
to say their entire DSL network is obsolete.
http://goo.gl/exwqu



On 8/10/2011 12:57 PM, Tim Chown wrote:

On 10 Aug 2011, at 16:11, Scott Helms wrote:


Neither of these are true, though in the future we _might_ have deployable 
technology that allows for automated routing setup (though I very seriously 
doubt it) in the home.  Layer 2 isolation is both easier and more reliable than 
attempting it at layer 3 which is isolation by agreement, i.e. it doesn't 
really exist.

Well, there is some new effort on this in the homenet WG in IETF.

For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use it in 
our enterprise since we have multiple multicast video channels in use.

Tim


On 8/10/2011 9:02 AM, Owen DeLong wrote:

Bridging eliminates the multicast isolation that you get from routing.

This is not a case for bridging, it's a case for making it possible to do real
routing in the home and we now have the space and the technology to
actually do it in a meaningful and sufficiently automatic way as to be
applicable to Joe 6-Mac.


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

http://twitter.com/kscotthelms




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

http://twitter.com/kscotthelms





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

http://twitter.com/kscotthelms

RE: Experience with Juniper MX-80s

[Mark Meijerink]

Babak,

For one of our customers we run two MX-80's. Both with two full routing peers 
plus a lot of other smaller BGP peerings at a local IX. So far no strange 
behaviour or poor performance. Peerings are all IPv4 and IPv6. I don't know if 
you would need specific features but for the basic border router functionality 
it seems to perform as expected.


Regards,
 Mark
 

-Original Message-
From: Babak Pasdar [mailto:bpas...@batblue.com] 
Sent: Thursday, August 11, 2011 3:44 PM
To: nanog@nanog.org
Subject: Experience with Juniper MX-80s

Hello NANOG Group,

I am curious if anyone has any experiences positive or negative with Juniper 
MX-80s.  Our recent experience with Juniper has not been great both in terms of 
new product offerings (SRX) and software bugs in the recent revs of Junos for 
the MX platform.  I want to know if the MX-80 functions as advertised and in 
specific can properly handle two full IPv4 and IPv6 BGP feeds 

Thanks in advance,

Babak 

--
Babak Pasdar
President & CEO | Certified Ethical Hacker
Bat Blue Corporation | Integrity . Privacy . Availability . Performance
(p) 212.461.3322 x3005 | (f) 212.584. | (w) www.BatBlue.com

Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games

Bat Blue's AS: 25885 | BGP Policy | Peering Policy

Receive Bat Blue's Daily Security Intelligence Report

Bat Blue's Legal Notice

Re: IPv6 end user addressing

[Michael Thomas]

On 08/11/2011 11:18 AM, Owen DeLong wrote:

On Aug 11, 2011, at 10:41 AM, sth...@nethelp.no wrote:

   

And your average home user, whose WiFi network is an open network named
"linksys" is going to do that how?
 

Because the routers that come on pantries and refrigerators will probably be
made by people smarter than the folks at Linksys?
   

One could argue that routing and access control is even less of a core
business feature for pantry and refrigerator manufacturers than it is
for Linksys. So I wouldn't rule this out - but I'm definitely in the
sceptical camp.

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

Let's face it... CPE security needs are going to be radically different and 
consumer
expectations are going to rise quickly in this area with IPv6.

I suspect both refrigerator/pantry makers _AND_ Linksys et. al. will be forced
to adapt.
   


Radically? How so? I have little confidence that the urge to do as little
as possible about security is going to change just because of IPv6. The
goal of router manufacturers is to turn a profit, not save the world.

Mike

Re: IPv6 end user addressing

[Jeff Johnstone]

On Thu, Aug 11, 2011 at 10:52 AM, Greg Ihnen  wrote:

>
> On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote:
>
> >
> > On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
> >
> >> Owen wrote:
> >>
> >>> -Original Message-
> >>> From: Owen DeLong [mailto:o...@delong.com]
> >>> Sent: Wednesday, August 10, 2011 9:58 PM
> >>> To: William Herrin
> >>> Cc: nanog@nanog.org
> >>> Subject: Re: IPv6 end user addressing
> >>>
> >>>
> >>> On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
> >>>
>  On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong 
> >> wrote:
> >> Someday, I expect the pantry to have a barcode reader on it
> >>> connected back
> >> a computer setup for the kitchen someday.  Most of us already use
> >>> barcode
> >> readers when we shop so its not a big step to home use.
> >
> > Nah... That's short-term thinking. The future holds advanced
> >>> pantries with
> > RFID sensors that know what is in the pantry and when they were
> >>> manufactured,
> > what their expiration date is, etc.
> 
>  And since your can of creamed corn is globally addressable, the rest
>  of the world knows what's in your pantry too. ;)
> 
> >>>
> >>> This definitely helps explain your misconceptions about NAT as a
> >>> security tool.
> >>>
> >>>
> >>> Globally addressable != globally reachable.
> >>>
> >>> Things can have global addresses without having global reachability.
> >>> There are
> >>> these tools called access control lists and routing policies. Perhaps
> >>> you've heard
> >>> of them. They can be quite useful.
> >>
> >> And your average home user, whose WiFi network is an open network named
> >> "linksys" is going to do that how?
> >>
> >
> > Because the routers that come on pantries and refrigerators will probably
> be
> > made by people smarter than the folks at Linksys?
> >
> > Owen
> >
> >
>
> I respectfully disagree. If appliance manufacturers jump on the bandwagon
> to make their device *Internet Ready!* we'll see appliance makers who have
> way less networking experience than Linksys/Cisco getting into the fray. I
> highly doubt the pontifications of these Good Morning America technology
> gurus who predict all these changes are coming to the home. Do we really
> think appliance manufacturers are going to agree on standards for keeping
> track of how much milk is in the fridge, especially as not just
> manufacturing but also engineering is moving to countries like China? How
> about the predictions that have been around for years about appliances which
> will alert the manufacturer about impending failure so they can call you and
> you can schedule the repair before there's a breakdown? Remember that one?
> We don't even have an "appliance about to break, call repairman" idiot light
> on appliances yet.
>
> But I predict the coming of IPv6 to the home in a big way will have
> unintended consequences.
>
> I think the big shock for home users regarding IPv6 will be suddenly having
> their IPv4 NAT firewall being gone and all their devices being exposed naked
> to everyone on the internet. Suddenly all their security shortcomings (no
> passwords, "password" for the password etc) are going to have catastrophic
> consequences. I foresee an exponential leap in the  number of hacks of
> consumer devices which will have repercussions well beyond their local
> network. In my opinion that's going to be the biggest problem with IPv6, not
> all the concerns about the inner workings of the protocols. I'm guessing the
> manufacturers of consumer grade networkable devices are still thinking about
> security as it applies to LANs with rfc 1918 address space behind a firewall
> and haven't rethought security as it applies to IPv6.
>
> Greg
>

+1

I think this is currently the biggest hole in IPV6 adoption. We need a drop
in firewall appliance along the lines of IPCOP for IPV6. This type of closed
unless tinkered with protection would encourage people to try it out and not
be too scared to move forward. This is a huge opportunity for some
Company/Open Source Developers Group to grab a huge chucnk of an emerging
market...   hint hint :)

cheers
Jeff

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 11, 2011, at 10:41 AM, sth...@nethelp.no wrote:

>>> And your average home user, whose WiFi network is an open network named
>>> "linksys" is going to do that how?
>> 
>> Because the routers that come on pantries and refrigerators will probably be
>> made by people smarter than the folks at Linksys?
> 
> One could argue that routing and access control is even less of a core
> business feature for pantry and refrigerator manufacturers than it is
> for Linksys. So I wouldn't rule this out - but I'm definitely in the
> sceptical camp.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

Let's face it... CPE security needs are going to be radically different and 
consumer
expectations are going to rise quickly in this area with IPv6.

I suspect both refrigerator/pantry makers _AND_ Linksys et. al. will be forced
to adapt.

Owen

Re: IPv6 end user addressing

[Chris Adams]

Once upon a time, Owen DeLong  said:
> Because the routers that come on pantries and refrigerators will probably be
> made by people smarter than the folks at Linksys?

That's highly doubtful, especially when Linksys is the "best" networking
equipment the average person will buy (at Best Buy, Wal-Mart, etc.).

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

Re: IPv6 end user addressing

[Greg Ihnen]

On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote:

> 
> On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:
> 
>> Owen wrote:
>> 
>>> -Original Message-
>>> From: Owen DeLong [mailto:o...@delong.com]
>>> Sent: Wednesday, August 10, 2011 9:58 PM
>>> To: William Herrin
>>> Cc: nanog@nanog.org
>>> Subject: Re: IPv6 end user addressing
>>> 
>>> 
>>> On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
>>> 
 On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong 
>> wrote:
>> Someday, I expect the pantry to have a barcode reader on it
>>> connected back
>> a computer setup for the kitchen someday.  Most of us already use
>>> barcode
>> readers when we shop so its not a big step to home use.
> 
> Nah... That's short-term thinking. The future holds advanced
>>> pantries with
> RFID sensors that know what is in the pantry and when they were
>>> manufactured,
> what their expiration date is, etc.
 
 And since your can of creamed corn is globally addressable, the rest
 of the world knows what's in your pantry too. ;)
 
>>> 
>>> This definitely helps explain your misconceptions about NAT as a
>>> security tool.
>>> 
>>> 
>>> Globally addressable != globally reachable.
>>> 
>>> Things can have global addresses without having global reachability.
>>> There are
>>> these tools called access control lists and routing policies. Perhaps
>>> you've heard
>>> of them. They can be quite useful.
>> 
>> And your average home user, whose WiFi network is an open network named
>> "linksys" is going to do that how?
>> 
> 
> Because the routers that come on pantries and refrigerators will probably be
> made by people smarter than the folks at Linksys?
> 
> Owen
> 
> 

I respectfully disagree. If appliance manufacturers jump on the bandwagon to 
make their device *Internet Ready!* we'll see appliance makers who have way 
less networking experience than Linksys/Cisco getting into the fray. I highly 
doubt the pontifications of these Good Morning America technology gurus who 
predict all these changes are coming to the home. Do we really think appliance 
manufacturers are going to agree on standards for keeping track of how much 
milk is in the fridge, especially as not just manufacturing but also 
engineering is moving to countries like China? How about the predictions that 
have been around for years about appliances which will alert the manufacturer 
about impending failure so they can call you and you can schedule the repair 
before there's a breakdown? Remember that one? We don't even have an "appliance 
about to break, call repairman" idiot light on appliances yet.

But I predict the coming of IPv6 to the home in a big way will have unintended 
consequences.

I think the big shock for home users regarding IPv6 will be suddenly having 
their IPv4 NAT firewall being gone and all their devices being exposed naked to 
everyone on the internet. Suddenly all their security shortcomings (no 
passwords, "password" for the password etc) are going to have catastrophic 
consequences. I foresee an exponential leap in the  number of hacks of consumer 
devices which will have repercussions well beyond their local network. In my 
opinion that's going to be the biggest problem with IPv6, not all the concerns 
about the inner workings of the protocols. I'm guessing the manufacturers of 
consumer grade networkable devices are still thinking about security as it 
applies to LANs with rfc 1918 address space behind a firewall and haven't 
rethought security as it applies to IPv6.

Greg

Re: IPv6 end user addressing

[sthaug]

> > And your average home user, whose WiFi network is an open network named
> > "linksys" is going to do that how?
> 
> Because the routers that come on pantries and refrigerators will probably be
> made by people smarter than the folks at Linksys?

One could argue that routing and access control is even less of a core
business feature for pantry and refrigerator manufacturers than it is
for Linksys. So I wouldn't rule this out - but I'm definitely in the
sceptical camp.

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

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote:

> Owen wrote:
> 
>> -Original Message-
>> From: Owen DeLong [mailto:o...@delong.com]
>> Sent: Wednesday, August 10, 2011 9:58 PM
>> To: William Herrin
>> Cc: nanog@nanog.org
>> Subject: Re: IPv6 end user addressing
>> 
>> 
>> On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
>> 
>>> On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong 
> wrote:
> Someday, I expect the pantry to have a barcode reader on it
>> connected back
> a computer setup for the kitchen someday.  Most of us already use
>> barcode
> readers when we shop so its not a big step to home use.
 
 Nah... That's short-term thinking. The future holds advanced
>> pantries with
 RFID sensors that know what is in the pantry and when they were
>> manufactured,
 what their expiration date is, etc.
>>> 
>>> And since your can of creamed corn is globally addressable, the rest
>>> of the world knows what's in your pantry too. ;)
>>> 
>> 
>> This definitely helps explain your misconceptions about NAT as a
>> security tool.
>> 
>> 
>> Globally addressable != globally reachable.
>> 
>> Things can have global addresses without having global reachability.
>> There are
>> these tools called access control lists and routing policies. Perhaps
>> you've heard
>> of them. They can be quite useful.
> 
> And your average home user, whose WiFi network is an open network named
> "linksys" is going to do that how?
> 

Because the routers that come on pantries and refrigerators will probably be
made by people smarter than the folks at Linksys?

Owen

RE: IPv6 end user addressing

[Frank Bulk]

This same Vendor C wants us to upgrade our 7206VXR's to ASR1K's just so we
have the (hopefully working) IPv6 features in IOS-XE that are broken in
12.x.

Frank

-Original Message-
From: Mark Newton [mailto:new...@internode.com.au] 
Sent: Wednesday, August 10, 2011 10:12 PM
To: Cameron Byrne
Cc: NANOG
Subject: Re: IPv6 end user addressing


On 11/08/2011, at 12:30 PM, Cameron Byrne wrote:
> Finally a useful post in this thread.  Good work on the deployment of real
ipv6!
> 

Thanks. And thanks to Vendor-C for helping us through it.  The IPv6
Broadband
featureset on the ASR platform starting from IOS-XR 3.1 is a vast
improvement
on its predecessors.

Biggest hassle with IPv6 in production right now:  DNS support is woefully 
undercooked.  I don't think anyone has put anywhere near as much effort into
making it fluid, user-friendly, and automated.  Simple questions like, "How
are reverse mappings supposed to work when you can't predict an end-user's
address?" have no good answer.  If any systems folks want a nice meaty
problem
domain to focus their efforts on, DNS would be da shiznit.

  - mark

--
Mark Newton   Email:  new...@internode.com.au
(W)
Network Engineer  Email:  new...@atdot.dotat.org
(H)
Internode Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: OSPF vs IS-IS

[Jason Duerstock]

On Thu, Aug 11, 2011 at 8:57 AM, CJ  wrote:

> Hey all,
>  Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
> are running IS-IS but we are redesigning our core and now would be a good
> time to switch. I would like to switch to OSPF, mostly because of
> familiarity with OSPF over IS-IS.
>  What does everyone think?
>
> --
> CJ
>
> http://convergingontheedge.com 
>

Granted, we're not a service provider, so we operate on a different scale
here, but one interesting trick that can be done with ISIS (at least on
Cisco) is this:

router a
---
router isis
advertise passive-only

interface loopback0
ip address 10.1.1.1 255.255.255.255

interface vlan2
ip unnumbered loopback0
ip router isis
isis network point-to-point


router b
---
(copy router isis definition from router a)

interface loopback0
ip address 10.1.1.2 255.255.255.255

(copy vlan2 definition from router a)

---

This removes the associated headaches with /30s or /31s in having to keep
track of their allocation, as well as having them clog the your routing
table.

-waits for replies stating why this is a bad idea-

Now, if I could just get isis-per-vrf-instance support on the Catalyst 6500.

Jason

Re: OSPF vs IS-IS

[CJ]

Awesome, I was thinking the same thing. Most experience is OSPF so it only
makes sense.

That is a good tip about OSPFv3 too. I will have to look more deeply into
OSPFv3.

Thanks,

-CJ

On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie  wrote:

> Having run both on some good sized networks, I can tell you to run
> what your ops folks know best.  We can debate all day the technical
> merits of one v another, but end of day, it always comes down to your
> most jr ops eng having to make a change at 2 am, you need to design
> for this case, if your using OSPF today and they know OSPF I'd say
> stick with it to reduce the chance of things blowing up at 2am when
> someone tries to 'fix' something else.
>
> -jim
>
> On Thu, Aug 11, 2011 at 10:29 AM, William Cooper 
> wrote:
> > I'm totally in concurrence with Stephan's point.
> >
> > Couple of things to consider: a) deciding to migrate to either ISIS or
> > OSPFv3 from another protocol is still migrating to a new protocol
> > and b) even in the case of migrating to OSPFv3, there are fairly
> > significant changes in behavior from OSPFv2 to be aware of (most
> > notably
> > authentication, but that's fodder for another conversation).
> >
> > -Tony
> >
> > On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant
> >  wrote:
> >> Well up until not too long ago, to support IPv6 you would run OSPFv3 and
> for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no
> longer the case with support for IPv4 NLRI in OSPFv3.
> >>
> >> The only reason in my opinion to run IS-IS rather than OSPF today is due
> to the fact that IS-IS is decoupled from IP making it less vulnerable to
> attacks.
> >>
> >> Stefan Fouant
> >> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
> >> Technical Trainer, Juniper Networks
> >> http://www.shortestpathfirst.net
> >> http://www.twitter.com/sfouant
> >>
> >> Sent from my iPad
> >>
> >> On Aug 11, 2011, at 8:57 AM, CJ  wrote:
> >>
> >>> Hey all,
> >>> Is there any reason to run IS-IS over OSPF in the SP core? Currently,
> we
> >>> are running IS-IS but we are redesigning our core and now would be a
> good
> >>> time to switch. I would like to switch to OSPF, mostly because of
> >>> familiarity with OSPF over IS-IS.
> >>> What does everyone think?
> >>>
> >>> --
> >>> CJ
> >>>
> >>> http://convergingontheedge.com 
> >>
> >>
> >
> >
>



-- 
CJ

http://convergingontheedge.com 

Re: OSPF vs IS-IS

[Justin M. Streiner]

On Thu, 11 Aug 2011, jim deleskie wrote:


Having run both on some good sized networks, I can tell you to run
what your ops folks know best.  We can debate all day the technical
merits of one v another, but end of day, it always comes down to your
most jr ops eng having to make a change at 2 am, you need to design
for this case, if your using OSPF today and they know OSPF I'd say
stick with it to reduce the chance of things blowing up at 2am when
someone tries to 'fix' something else.


Agreed.  I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago 
as part of an IPv6 rollout, and one of the key deciding factors in going 
with OSPFv3 over IS-IS was that our ops folks are much more familiar with 
OSPFv2.  While there are difference between OSPFv2 and OSPFv3 in how they 
work, the learning curve is a lot less steep than going from OSPFv2 to 
IS-IS.


jms


On Thu, Aug 11, 2011 at 10:29 AM, William Cooper  wrote:

I'm totally in concurrence with Stephan's point.

Couple of things to consider: a) deciding to migrate to either ISIS or
OSPFv3 from another protocol is still migrating to a new protocol
and b) even in the case of migrating to OSPFv3, there are fairly
significant changes in behavior from OSPFv2 to be aware of (most
notably
authentication, but that's fodder for another conversation).

-Tony

On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant
 wrote:

Well up until not too long ago, to support IPv6 you would run OSPFv3 and for 
IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer 
the case with support for IPv4 NLRI in OSPFv3.

The only reason in my opinion to run IS-IS rather than OSPF today is due to the 
fact that IS-IS is decoupled from IP making it less vulnerable to attacks.

Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

Sent from my iPad

On Aug 11, 2011, at 8:57 AM, CJ  wrote:


Hey all,
Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
are running IS-IS but we are redesigning our core and now would be a good
time to switch. I would like to switch to OSPF, mostly because of
familiarity with OSPF over IS-IS.
What does everyone think?

--
CJ

http://convergingontheedge.com 

Experience with Juniper MX-80s

[Babak Pasdar]

Hello NANOG Group,

I am curious if anyone has any experiences positive or negative with Juniper 
MX-80s.  Our recent experience with Juniper has not been great both in terms of 
new product offerings (SRX) and software bugs in the recent revs of Junos for 
the MX platform.  I want to know if the MX-80 functions as advertised and in 
specific can properly handle two full IPv4 and IPv6 BGP feeds 

Thanks in advance,

Babak 

--
Babak Pasdar
President & CEO | Certified Ethical Hacker
Bat Blue Corporation | Integrity . Privacy . Availability . Performance
(p) 212.461.3322 x3005 | (f) 212.584. | (w) www.BatBlue.com

Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games

Bat Blue's AS: 25885 | BGP Policy | Peering Policy

Receive Bat Blue's Daily Security Intelligence Report

Bat Blue's Legal Notice

Re: OSPF vs IS-IS

[jim deleskie]

Having run both on some good sized networks, I can tell you to run
what your ops folks know best.  We can debate all day the technical
merits of one v another, but end of day, it always comes down to your
most jr ops eng having to make a change at 2 am, you need to design
for this case, if your using OSPF today and they know OSPF I'd say
stick with it to reduce the chance of things blowing up at 2am when
someone tries to 'fix' something else.

-jim

On Thu, Aug 11, 2011 at 10:29 AM, William Cooper  wrote:
> I'm totally in concurrence with Stephan's point.
>
> Couple of things to consider: a) deciding to migrate to either ISIS or
> OSPFv3 from another protocol is still migrating to a new protocol
> and b) even in the case of migrating to OSPFv3, there are fairly
> significant changes in behavior from OSPFv2 to be aware of (most
> notably
> authentication, but that's fodder for another conversation).
>
> -Tony
>
> On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant
>  wrote:
>> Well up until not too long ago, to support IPv6 you would run OSPFv3 and for 
>> IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no 
>> longer the case with support for IPv4 NLRI in OSPFv3.
>>
>> The only reason in my opinion to run IS-IS rather than OSPF today is due to 
>> the fact that IS-IS is decoupled from IP making it less vulnerable to 
>> attacks.
>>
>> Stefan Fouant
>> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
>> Technical Trainer, Juniper Networks
>> http://www.shortestpathfirst.net
>> http://www.twitter.com/sfouant
>>
>> Sent from my iPad
>>
>> On Aug 11, 2011, at 8:57 AM, CJ  wrote:
>>
>>> Hey all,
>>> Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
>>> are running IS-IS but we are redesigning our core and now would be a good
>>> time to switch. I would like to switch to OSPF, mostly because of
>>> familiarity with OSPF over IS-IS.
>>> What does everyone think?
>>>
>>> --
>>> CJ
>>>
>>> http://convergingontheedge.com 
>>
>>
>
>

Re: OSPF vs IS-IS

[William Cooper]

I'm totally in concurrence with Stephan's point.

Couple of things to consider: a) deciding to migrate to either ISIS or
OSPFv3 from another protocol is still migrating to a new protocol
and b) even in the case of migrating to OSPFv3, there are fairly
significant changes in behavior from OSPFv2 to be aware of (most
notably
authentication, but that's fodder for another conversation).

-Tony

On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant
 wrote:
> Well up until not too long ago, to support IPv6 you would run OSPFv3 and for 
> IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no 
> longer the case with support for IPv4 NLRI in OSPFv3.
>
> The only reason in my opinion to run IS-IS rather than OSPF today is due to 
> the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
>
> Stefan Fouant
> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
> Technical Trainer, Juniper Networks
> http://www.shortestpathfirst.net
> http://www.twitter.com/sfouant
>
> Sent from my iPad
>
> On Aug 11, 2011, at 8:57 AM, CJ  wrote:
>
>> Hey all,
>> Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
>> are running IS-IS but we are redesigning our core and now would be a good
>> time to switch. I would like to switch to OSPF, mostly because of
>> familiarity with OSPF over IS-IS.
>> What does everyone think?
>>
>> --
>> CJ
>>
>> http://convergingontheedge.com 
>
>

Re: network issue help

[mikea]

On Thu, Aug 11, 2011 at 10:39:59AM +1000, Matthew Palmer wrote:
> On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote:
> > Is there an acronym for RTFM when there are a volume of manuals that need 
> > to be read?
> 
> FOAD, perhaps?

Well, there's ADD: Attention Deficit Disorder. 
Then there's ADHD: Attendion Deficit Hyperactivity Disorder. 
And there's ADCD: Absent During Clue Distribution. 

I think #3 may fit best. 

-- 
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin 

Re: OSPF vs IS-IS

[Stefan Fouant]

Well up until not too long ago, to support IPv6 you would run OSPFv3 and for 
IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer 
the case with support for IPv4 NLRI in OSPFv3.

The only reason in my opinion to run IS-IS rather than OSPF today is due to the 
fact that IS-IS is decoupled from IP making it less vulnerable to attacks.

Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

Sent from my iPad

On Aug 11, 2011, at 8:57 AM, CJ  wrote:

> Hey all,
> Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
> are running IS-IS but we are redesigning our core and now would be a good
> time to switch. I would like to switch to OSPF, mostly because of
> familiarity with OSPF over IS-IS.
> What does everyone think?
> 
> -- 
> CJ
> 
> http://convergingontheedge.com 

OSPF vs IS-IS

[CJ]

Hey all,
 Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
are running IS-IS but we are redesigning our core and now would be a good
time to switch. I would like to switch to OSPF, mostly because of
familiarity with OSPF over IS-IS.
 What does everyone think?

-- 
CJ

http://convergingontheedge.com 

RE: IPv6 end user addressing

[Jamie Bowden]

Owen wrote:

> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Wednesday, August 10, 2011 9:58 PM
> To: William Herrin
> Cc: nanog@nanog.org
> Subject: Re: IPv6 end user addressing
> 
> 
> On Aug 10, 2011, at 6:46 PM, William Herrin wrote:
> 
> > On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong 
wrote:
> >>> Someday, I expect the pantry to have a barcode reader on it
> connected back
> >>> a computer setup for the kitchen someday.  Most of us already use
> barcode
> >>> readers when we shop so its not a big step to home use.
> >>
> >> Nah... That's short-term thinking. The future holds advanced
> pantries with
> >> RFID sensors that know what is in the pantry and when they were
> manufactured,
> >> what their expiration date is, etc.
> >
> > And since your can of creamed corn is globally addressable, the rest
> > of the world knows what's in your pantry too. ;)
> >
> 
> This definitely helps explain your misconceptions about NAT as a
> security tool.
> 
> 
> Globally addressable != globally reachable.
> 
> Things can have global addresses without having global reachability.
> There are
> these tools called access control lists and routing policies. Perhaps
> you've heard
> of them. They can be quite useful.

And your average home user, whose WiFi network is an open network named
"linksys" is going to do that how?

Jamie

Re: v4/v6 dns thoughts?

[Owen DeLong]

On Aug 10, 2011, at 9:01 PM, Andrew Parnell wrote:

> On Tue, Aug 9, 2011 at 7:36 PM, Owen DeLong  wrote:
>> 
>> I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. 
>> There's
>> really no advantage to do it. Most tools either have separate IPv4/IPv6 
>> variants
>> or have command-line switches for address-family control if you care.
> 
> For most tools that I ordinarily use, I would certainly agree with
> this.  The only exception might be from a web browser; while there are
> ways that they can be reconfigured to only use certain IP versions in
> certain cases, it is probably more straightforward to use
> www.ipvN.domain.tld or a similar name.
> 

In a web browser, I don't care unless I'm troubleshooting.

If I'm troubleshooting, my web browser of choice is probably wget rather
than one of the kitchen sink GUI based browsers. It turns out that wget
supports the flag in question.

Owen

Re: IPv6 end user addressing

[Owen DeLong]

On Aug 10, 2011, at 8:29 PM, Joel Jaeggli wrote:

> 
> On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote:
> 
>> On 2011-08-11 12:45, james machado wrote:
>> 
>>> what is the life expectancy of IPv6?  It won't live forever and we
>>> can't reasonably expect it too.  I understand we don't want run out of
>>> addresses in the next 10-40 years but what about 100? 200? 300?
>>> 
>>> We will run out and our decedents will go through re-numbering again.
>>> The question becomes what is the life expectancy of IPv6 and does the
>>> allocation plan make a reasonable attempt to run out of addresses
>>> around the end of the expected life of IPv6.
>> 
>> Well, we know that the human population will stabilise somewhere below
>> ten billion by around 2050. The current unicast space provides for about
>> 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current
>> level of engineering common sense - i.e. the address space will begin to be
>> really full when there are about 25% of those /48s being routed... that makes
>> 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman
>> and child. (Or about 25 million /64s if you prefer.)
> 
> It's not the humans that are going to soak up the address space, so it seems 
> a little misguided to count up the humans a reference for the bounding 
> properties on growth. That said I think 2000::/3 will last long enough, that 
> we shouldn't be out rewriting policy anytime soon.
> 

I disagree. I think current policy in several RIRs (APNIC, especially) is far 
too conservative
and that we do need to rewrite it. That's why I submitted prop-090 which has 
taken the
feedback I received into account and become prop-098.

Owen

Communications networks "will be closed down"

[Alexander Harrowell]

http://blogs.ft.com/westminster/2011/08/uk-riots-david-cameron-
announces-his-prescription/

I feel this is operational or at least potentially so.

-- 
The only thing worse than e-mail disclaimers...is people who send e-mail 
to lists complaining about them


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

Re: IPv6 end user addressing

[Eugen Leitl]

On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote:

> Well, we know that the human population will stabilise somewhere below
> ten billion by around 2050. The current unicast space provides for about

How about the machine population? How about self-replicating systems?
How about geography-based address allocation, to go away with global routing
tables? How about InterPlaNet, such as LEO routers, solar power
satellites, controlling industrial production on the Moon and elsewhere?

I don't expect IPv6 will last much longer than IPv4. And that's probably
a good thing.

> 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current
> level of engineering common sense - i.e. the address space will begin to be
> really full when there are about 25% of those /48s being routed... that makes
> 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman
> and child. (Or about 25 million /64s if you prefer.)
> 
> At that point, IANA would have to release unicast space other than 2000::/3
> and we could start again with a new allocation policy.
> 
> I am *really* not worried about this. Other stuff, such as BGP4, will break
> irrevocably long before this.

-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

Re: 4g hack

[Joakim Aronius]

* Christopher Morrow (morrowc.li...@gmail.com) wrote:
> On Thu, Aug 11, 2011 at 2:32 AM, Charles N Wyble
>  wrote:
> > http://seclists.org/fulldisclosure/2011/Aug/76
> >
> > Wondering what folks think about this? If this was true then we just
> > entered a whole new era of mass WAN exploitation.
> >
> 
> This isn't really all that new is it? haven't people been able to buy
> 3g/pcs/etc antennae and such off ebay for a while and intercept
> conversations/data/etc for a long time? GSM was 'hacked' (decrypted
> via some rainbow tables) several years ago as well.
> 
> If you ship it over the air and there isn't a reasonable encryption
> scheme in place, don't you expect it to be seen?

GSM and GPRS are vulnerable to MitM due to lack of two factor authentication 
etc. WCDMA (3G) and LTE (4G) should be safe as they have much better security. 
Not sure about 3GPP2 (CDMA) or WiMAX systems, perhaps early version of CDMA has 
similar problems as GSM. But saying that '4G' is vulnerable is a pretty broad 
statement as it consists of at least LTE and WiMAX, and some US operators also 
refer to their WCDMA HSPA as 4G. There is also a difference between 'the 
standard has security flaws' and 'the operator has deployed an insecure 
network' as operators might run their network with security features turned off.

Anyway, the paranoid should turn of GSM and run WCDMA instead.

/Joakim 

Re: 4g hack

[Christopher Morrow]

On Thu, Aug 11, 2011 at 2:32 AM, Charles N Wyble
 wrote:
> http://seclists.org/fulldisclosure/2011/Aug/76
>
> Wondering what folks think about this? If this was true then we just
> entered a whole new era of mass WAN exploitation.
>

This isn't really all that new is it? haven't people been able to buy
3g/pcs/etc antennae and such off ebay for a while and intercept
conversations/data/etc for a long time? GSM was 'hacked' (decrypted
via some rainbow tables) several years ago as well.

If you ship it over the air and there isn't a reasonable encryption
scheme in place, don't you expect it to be seen?