Re: Addressing plan exercise for our IPv6 course

[rodolfo . garciapenas]

Hi!

this page may be useful

http://www.getipv6.info/index.php/IPv6_Addressing_Plans

Rodolfo



   
 Simon Perreault   
  Para 
   Marco Hogewoning
 21/07/2010 22:02   
cc 
   Nanog  
Asunto 
   Re: Addressing plan exercise for
   our IPv6 course 
   
   
   
   
   
   




On 2010-07-21 14:47, Marco Hogewoning wrote:
> For a novice ? I wouldn't recommend it. From what I get back 'in the
field' it's already hard enough to get people familliar to the whole
concept of hexadecimal without going into bit level. But then again, if you
are a fairly technical company maybe you can get away with it.

Not disagreeing, but here's a tool to make it easier:

http://www.ipv6book.ca/allocation.html

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server--> http://numb.viagenie.ca
vCard 4.0   --> http://www.vcarddav.org


_
Mensaje analizado y protegido por Telefonica Empresas

Re: Looking for comments

[William Herrin]

On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong  wrote:
>>> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
>> There is a third major challenge to dual-stack that isn't addressed in
>> the document: differing network security models that must deliver the
>> same result for the same collection of hosts regardless of whether
>> Ipv4 or v6 is selected. I can throw a COTS d-link box with
>> address-overloaded NAT on a connection and have reasonably effective
>> network security and anonymity in IPv4. Achieving comparable results
>> in the IPv6 portion of the dual stack on each of those hosts is
>> complicated at best.
>>
> Actually, it isn't particularly hard at all... Turn on privacy addressing
> on each of the hosts (if it isn't on by default) and then put a linux
> firewall in front of them with a relatively simple ip6tables configuration
> for outbound only.

>From the lack of dispute, can I infer agreement with the remainder of
my comments wrt mitigations for the "one of my addresses doesn't work"
problem and the impracticality of the document's section 4.3 and 4.4
for wide scale Ipv6 deployment?

Regards,
Bill Herrin


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

Re: v6 bgp peer costs?

[Elmar K. Bins]

mle...@he.net (Mike Leber) wrote:

> 
> You can get a free IPv6 BGP tunnel from Hurricane Electric at 
> http://tunnelbroker.net
> 
> We have tunnel servers spread through out the world, so typically the 
> nearest server has reasonably low latency from your location.
> 
> Of course our main business is selling wholesale native IPv6 and IPv4 
> transit, however you don't have to be a paying customer to use our free 
> service.

> 
> On 7/21/10 12:08 PM, Zaid Ali wrote:
>> I currently have a v4 BGP session with AS 701 and recently requested a v6
>> BGP session to which I was told a tunnel session will be provided (Same
>> circuit would be better but whatever!). Towards the final stage in
>> discussions I was told that it will cost $1500. I find this quite 

Mike, Mike,

I still wonder how you are able to sell the stuff that you are *also*
giving away for free (minus the physical port) and that admittedly works
like a charm...

Elmar.

PS: Keep up the good tunne^Wwork!
PPS: Any plans on having something inside mainland China?

Re: "vpn exchange point"

[Christopher Morrow]

equinix ethernet exchange

On Wed, Jul 21, 2010 at 10:59 PM, Marshall Eubanks  wrote:
>
> On Jul 21, 2010, at 5:43 PM, Bill Woodcock wrote:
>
>>
>> On Jul 21, 2010, at 12:59 PM, William McCall wrote:
>>
>>> OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure
>>> that I've (personally) ever heard of an IXP for MPLS.
>>
>> Isn't that what one iteration of IXP-NSP in Japan was?  I seem to recall
>> that they talked about it a lot, back when MPLS was still trendy, but I
>> haven't heard word one about it for many years since.
>>
>
> The TelX Video Exchange
>
> http://www.telx.com/Products-Services/telx-video-exchange.html
>
> is supposed to be a MPLS to MPLS exchange with some tailoring for H.323 (and
> maybe SIP/RTP) video transport.
>
> Regards
>
>
>>                               -Bill
>>
>>
>>
>>
>>
>>
>>
>
>
>

Re: PCH.net down?

[Christopher Morrow]

On Thu, Jul 22, 2010 at 2:52 AM, Simon Horman  wrote:

> Thats quite a revelation. I assumed it tested from all points of
> the internet other than mine :^)

I suspect it simple does an equivalent of 'wget' of the hostname you
enter... the appengine api doesn't really permit much more than http/s
out I think :( of course it COULD run that wget to some external
service that queries from 100k other points of light, but really... I
bet it's just doing it to the hostname you enter.

-chris

Re: Root Zone DNSSEC Deployment Technical Status Update

[Bjørn Mork]

Jeffrey Ollie  writes:
> On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli  wrote:
>> On 7/16/10 11:07 AM, Tony Finch wrote:
>>>
>>> On Fri, 16 Jul 2010, Chris Adams wrote:

 A simple XSLT will transform it into any needed format.
>>>
>>> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
>>
>> anchors2keys will.
>
> Actually, it won't.  The ITAR anchors.xml and anchors2keys use a
> different XML schema than the root-anchors.xml does.

Just for the fun of it, I explored how difficult it would be
implementing something similar in perl using the excellent Net::DNS::SEC
module.  It was really simple: http://www.mork.no/~bjorn/rootanchor2keys.pl
Ugly as hell as usual with my perl code, but it works. And it is simple
enough to be verifiable.

You will need Net::DNS::SEC and XML::Simple from CPAN or your friendly
OS distribution (libnet-dns-sec-perl and libxml-simple-perl in Debian)



Bjørn

Re: Looking for comments

[Owen DeLong]

On Jul 22, 2010, at 12:49 AM, William Herrin wrote:

> On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong  wrote:
 http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
>>> There is a third major challenge to dual-stack that isn't addressed in
>>> the document: differing network security models that must deliver the
>>> same result for the same collection of hosts regardless of whether
>>> Ipv4 or v6 is selected. I can throw a COTS d-link box with
>>> address-overloaded NAT on a connection and have reasonably effective
>>> network security and anonymity in IPv4. Achieving comparable results
>>> in the IPv6 portion of the dual stack on each of those hosts is
>>> complicated at best.
>>> 
>> Actually, it isn't particularly hard at all... Turn on privacy addressing
>> on each of the hosts (if it isn't on by default) and then put a linux
>> firewall in front of them with a relatively simple ip6tables configuration
>> for outbound only.
> 
>> From the lack of dispute, can I infer agreement with the remainder of
> my comments wrt mitigations for the "one of my addresses doesn't work"
> problem and the impracticality of the document's section 4.3 and 4.4
> for wide scale Ipv6 deployment?
> 
No, merely resignation to the fact that you don't get it.

Owen

Re: Addressing plan exercise for our IPv6 course

[Alex Band]

Hi Antonio,

That diagram looks interesting. We currently use slides with a bunch  
of animation to explain to this concept, but it may be nice to have  
something like this that people can keep as a printed version.


By the way, this is what we think two possible answers are: http://bit.ly/9V5GfU

There are more options, but these two are the most convenient weighing  
all the up and downsides. Does anyone disagree?


Cheers,

Alex

On 22 Jul 2010, at 05:34, Antonio M. Moreiras wrote:


I think it is a very well planned exercise. I would suggest you not to
be straight in its execution. In some point, you could ask if the
decisions would be the same in cases with different conditions: more
pops, more users, less users, etc...

We have a similar exercise in our training at NIC.br and we use this
diagram to help the trainees understand the addresses:
http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/enderec-v6.pdf...
Maybe it could be useful.

Moreiras.

Em 22/07/10 00:19, Mark Smith escreveu:



I'm curious to hear if you think it's clear and useful.

Cheers,

Alex Band
RIPE NCC Trainer

(Big props go to Marco Hogewoning @XS4ALL)

Re: Looking for comments

[William Herrin]

On Thu, Jul 22, 2010 at 3:02 AM, Owen DeLong  wrote:
> On Jul 22, 2010, at 12:49 AM, William Herrin wrote:
>>> From the lack of dispute, can I infer agreement with the remainder of
>> my comments wrt mitigations for the "one of my addresses doesn't work"
>> problem and the impracticality of the document's section 4.3 and 4.4
>> for wide scale Ipv6 deployment?
>>
> No, merely resignation to the fact that you don't get it.

I see. Well, you want to engage in a genuine discussion of the
challenges which obstruct *my* deployment of Ipv6, you let me know.

Regards,
Bill Herrin

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

anyone seeing issues within the AT&T/SBC network today?

[Steven Fischer]

seeing better than 90% (approaching 100%) packet loss to a host within the
AT&T network today.  Seems to be the result of either a severed link or some
really munged up routing between AT&T and Verizon - from my traceroute, the
issue appears about 8 hops into the AT&T network.  Any insight into this is
greatly appreciated.

-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

Re: PCH.net down?

[Mikhail Strizhov]

Dead again?

Web page says "Could not connect: ".

Northern Colorado, US.

--
*Sincerely,*
*Mikhail Strizhov*
*Email: striz...@cs.colostate.edu 

*

On 07/21/2010 06:44 AM, Jason Lewis wrote:

This says it's not just down for me.  http://downforeveryoneorjustme.com/pch.net

Anyone else?

   

Re: PCH.net down?

[Mikeal Clark]

Up for me in Wi.

Sent from my iPhone

On Jul 22, 2010, at 12:47 PM, Mikhail Strizhov  
wrote:

> Dead again?
> 
> Web page says "Could not connect: ".
> 
> Northern Colorado, US.
> 
> -- 
> *Sincerely,*
> *Mikhail Strizhov*
> *Email: striz...@cs.colostate.edu 
> 
> *
> 
> On 07/21/2010 06:44 AM, Jason Lewis wrote:
>> This says it's not just down for me.  
>> http://downforeveryoneorjustme.com/pch.net
>> 
>> Anyone else?
>> 
>>   
> 

Re: PCH.net down?

[Bill Woodcock]

On Jul 22, 2010, at 10:47 AM, Mikhail Strizhov wrote:

> Dead again?
> Web page says "Could not connect: ".

The multi-threaded download that's been hammering our web servers is still 
going on.  We've just turned up a new server this morning, and expect to have 
the bulk-download processes moved over to it later today, offloading the stuff 
the rest of you are trying to use.  My apologies.  We're getting a lot of 
inquiries about it, so I'll try to post back to NANOG as soon as we think 
everything has been separated out and is working at full speed again.

-Bill

Re: "vpn exchange point"

[Michael Dillon]

> Do you know of any "vpn exchange point" implementations please? -I mean 
> something like IXP but for mpls vpns
>
> Let's say I'm an ISP that bought or merged with many small ISPs each with 
> it's own AS# and would like to start offering mpls vpn services end to end

In the MPLS world, this type of interconnect is called NNI (Network to
Network Interconnect)
and it needs to take into account things like COS mappings. I don't
know of anyone doing this
as an exchange, But I imagine that if you had a router with a private
ASN, you could always
do NNI with a different ASN on each port and therefore, achieve
something analogous to an
IXP.

But you could only do this if you control all the ASNs involved,
because vPn is a form of
private network, so you need a higher level of trust with the other
ASns. Most MPLS providers
only use this to extend their reach into a territory where they will
likely never build PoPs.
For instance, to get good coverage of Russia, population 150 million,
or the 4 Nordic
countries, you could either build loss-leader PoPs, spend lots of
money on longlining
or do NNI with an MPLS provider that has good coverage because they
focus on smaller
regional customers.

--Michael Dillon

P.S. If you do this, it would be interesting to report back to NANOG
on how you configured
it, and what are the strengths and weaknesses.

Re: "vpn exchange point"

[Christopher Morrow]

On Thu, Jul 22, 2010 at 3:46 PM, Michael Dillon
 wrote:
>> Do you know of any "vpn exchange point" implementations please? -I mean 
>> something like IXP but for mpls vpns
>>
>> Let's say I'm an ISP that bought or merged with many small ISPs each with 
>> it's own AS# and would like to start offering mpls vpn services end to end
>
> In the MPLS world, this type of interconnect is called NNI (Network to
> Network Interconnect)

hey look frame-relay! (joking, sorta, not really)

In almost all cases this is still done via the A version (or 1 version
of 4) mpls interconnect types where each customer VPN is broken down
to native-IP links (vlans most often I believe, sometimes frame dlcis!
:)) and the contracted cos/qos setup is replicated on the adjacent
provider's interface as well... as you (michael) pointed out though,
it's pretty much only done for 'i dont want to build in XXX' places.

Additionally, from my (admittedly limited involvement) understanding
these sorts of connections are notoriously problematic, painful and
ultimately expensive for the provider(s) in question :( boo.

> and it needs to take into account things like COS mappings. I don't
> know of anyone doing this
> as an exchange, But I imagine that if you had a router with a private
> ASN, you could always
> do NNI with a different ASN on each port and therefore, achieve
> something analogous to an
> IXP.

the real question is why? what's the business driver? what's the
support model? is it truly worthwhile?

-chris

Re: Looking for comments

[Brian E Carpenter]

Bill,

On 2010-07-22 19:49, William Herrin wrote:
> On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong  wrote:
 http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
>>> There is a third major challenge to dual-stack that isn't addressed in
>>> the document: differing network security models that must deliver the
>>> same result for the same collection of hosts regardless of whether
>>> Ipv4 or v6 is selected. I can throw a COTS d-link box with
>>> address-overloaded NAT on a connection and have reasonably effective
>>> network security and anonymity in IPv4. Achieving comparable results
>>> in the IPv6 portion of the dual stack on each of those hosts is
>>> complicated at best.
>>>
>> Actually, it isn't particularly hard at all... Turn on privacy addressing
>> on each of the hosts (if it isn't on by default) and then put a linux
>> firewall in front of them with a relatively simple ip6tables configuration
>> for outbound only.
> 
>>From the lack of dispute, can I infer agreement with the remainder of
> my comments wrt mitigations for the "one of my addresses doesn't work"
> problem and the impracticality of the document's section 4.3 and 4.4
> for wide scale Ipv6 deployment?

As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify
them), the document doesn't place them as first preference solutions.
However, the fact is that various *extremely* large operators find themselves
more or less forced into these scenarios by IPv4 exhaustion. I think it's
more reasonable to describe solutions for them than to rule their
problem out of order.

   Brian

Re: Looking for comments

[Nick Hilliard]

On 22/07/2010 22:38, Brian E Carpenter wrote:

As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify
them), the document doesn't place them as first preference solutions.
However, the fact is that various *extremely* large operators find themselves
more or less forced into these scenarios by IPv4 exhaustion.


Some of the extremely large operators have found themselves having to 
deploy ipv6 extensively in order to manage CPE devices and their 
infrastructure networks.  However, I'm not aware of any large provider 
which is deploying ipv6-only customer access products, either due to a 
shortage of ipv4 space or any other reason.  If you can supply names of 
providers doing this, I'd be very interested to hear.


That's not to say that they won't start doing this relatively shortly. 
And you correctly point out that we need to create solutions _now_ so 
that access providers will have feature equivalence when they start 
deploying ipv6 in anger on access / hosted networks.


This is a cue to get people on this list to shout at their vendors for 
ipv6 feature equivalence on their favourite kit.


Nick

Re: Addressing plan exercise for our IPv6 course

[Matthew Walster]

On 22 July 2010 14:11, Alex Band  wrote:
> There are more options, but these two are the most convenient weighing all
> the up and downsides. Does anyone disagree?

I never saw the point of assigning a /48 to a DSL customer. Surely the
better idea would be to assign your bog standard residential DSL
customer a /64 and assign them a /56 or /48 if they request it, routed
to an IP of their choosing.

For the rest of it, I largely agree, though.

M

Re: Looking for comments

[Mark Smith]

On Thu, 22 Jul 2010 23:57:22 +0100
Nick Hilliard  wrote:

> On 22/07/2010 22:38, Brian E Carpenter wrote:
> > As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to 
> > simplify
> > them), the document doesn't place them as first preference solutions.
> > However, the fact is that various *extremely* large operators find 
> > themselves
> > more or less forced into these scenarios by IPv4 exhaustion.
> 
> Some of the extremely large operators have found themselves having to 
> deploy ipv6 extensively in order to manage CPE devices and their 
> infrastructure networks.  However, I'm not aware of any large provider 
> which is deploying ipv6-only customer access products, either due to a 
> shortage of ipv4 space or any other reason.  If you can supply names of 
> providers doing this, I'd be very interested to hear.
> 

Does this qualify? What the customer sees is delivered over IPv6,
unlike the CPE management problem, where the ISP is the "IPv6 customer".

"IPv6: The Future of IPTV? In Japan it isn't the future, it's now."
http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm

> That's not to say that they won't start doing this relatively shortly. 
> And you correctly point out that we need to create solutions _now_ so 
> that access providers will have feature equivalence when they start 
> deploying ipv6 in anger on access / hosted networks.
> 
> This is a cue to get people on this list to shout at their vendors for 
> ipv6 feature equivalence on their favourite kit.
> 
> Nick
> 

Re: Looking for comments

[Franck Martin]

- Original Message -
> From: "Mark Smith" 
> 
> To: "Nick Hilliard" 
> Cc: "NANOG list" , "Brian E Carpenter" 
> 
> Sent: Friday, 23 July, 2010 12:17:21 PM
> Subject: Re: Looking for comments
> On Thu, 22 Jul 2010 23:57:22 +0100
> Nick Hilliard  wrote:
> 
> > On 22/07/2010 22:38, Brian E Carpenter wrote:
> > > As for those two scenarios (IPv6-only ISPs and IPv6-only clients,
> > > to simplify
> > > them), the document doesn't place them as first preference
> > > solutions.
> > > However, the fact is that various *extremely* large operators find
> > > themselves
> > > more or less forced into these scenarios by IPv4 exhaustion.
> >
> > Some of the extremely large operators have found themselves having
> > to
> > deploy ipv6 extensively in order to manage CPE devices and their
> > infrastructure networks. However, I'm not aware of any large
> > provider
> > which is deploying ipv6-only customer access products, either due to
> > a
> > shortage of ipv4 space or any other reason. If you can supply names
> > of
> > providers doing this, I'd be very interested to hear.
> >
> 
> Does this qualify? What the customer sees is delivered over IPv6,
> unlike the CPE management problem, where the ISP is the "IPv6
> customer".
> 
> "IPv6: The Future of IPTV? In Japan it isn't the future, it's now."
> http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm
> 
In the USA too, see netflix

Re: Addressing plan exercise for our IPv6 course

[Valdis . Kletnieks]

On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said:

> I never saw the point of assigning a /48 to a DSL customer. Surely the
> better idea would be to assign your bog standard residential DSL
> customer a /64 and assign them a /56 or /48 if they request it, routed
> to an IP of their choosing.

If they're using autoconfigure for IPv6 addresses, what happens if they want to
share that connection?  Giving them a /64 off the bat means that a very sizable
fraction of your users are going to call.

Phrased differently - how screwed would you be if you engineered your IPv4
network so the default was "one device only", and the customer had to call you
and ask for a network config change because they wanted to hook up a $50 home
wifi router?

If it doesn't make sense for IPv4, why would you want to do it for IPv6?


pgpo74DafKjhl.pgp
Description: PGP signature

Re: Addressing plan exercise for our IPv6 course

[Matthew Kaufman]

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

On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said:

  

I never saw the point of assigning a /48 to a DSL customer. Surely the
better idea would be to assign your bog standard residential DSL
customer a /64 and assign them a /56 or /48 if they request it, routed
to an IP of their choosing.



If they're using autoconfigure for IPv6 addresses, what happens if they want to
share that connection?  Giving them a /64 off the bat means that a very sizable
fraction of your users are going to call.

Phrased differently - how screwed would you be if you engineered your IPv4
network so the default was "one device only", and the customer had to call you
and ask for a network config change because they wanted to hook up a $50 home
wifi router?

If it doesn't make sense for IPv4, why would you want to do it for IPv6?
  
"Home wifi router" vendors will do whatever it takes to make this work, 
so of course in your scenario they simply implement NAT66 (whether or 
not IETF folks think it is a good idea) however they see fit and nobody 
calls.


Matthew Kaufman

Re: Addressing plan exercise for our IPv6 course

[Karl Auer]

On Thu, 2010-07-22 at 20:24 -0400, valdis.kletni...@vt.edu wrote:
> On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said:
> > I never saw the point of assigning a /48 to a DSL customer. Surely the
> > better idea would be to assign your bog standard residential DSL
> > customer a /64 and assign them a /56 or /48 if they request it, routed
> > to an IP of their choosing.
> 
> If they're using autoconfigure for IPv6 addresses, what happens if they want 
> to
> share that connection?  Giving them a /64 off the bat means that a very 
> sizable
> fraction of your users are going to call.

Um, but they will have 18 billion billion addresses in that /64. That
should do them, unless they want to subnet in the home. Which is not so
unusual, so while doing a /48 might be overkill, doing a /60 or even
a /56 off the bat is not such a silly idea.

Unless I've misunderstood Matthew, and he was suggesting that the /64 be
the link network. That would indeed effectively give the customer a
single address, unless it was being bridged rather than routed at the
CPE. Not sure bridging it is such a good idea - most people will
probably want their home networks to keep working even if the ISP has an
outage.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


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

Qwest NOC contact?

[James Kelty]

Could a clueful Qwest NOC engineer contact me off list regarding this:

jke...@zao:512 -> mtr --curses --no-dns --report --report-cycles=2 205.185.95.11
HOST: zao Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 208.85.40.5   0.0% 20.3   0.4   0.3   0.5   0.1
  2. 208.85.40.1   0.0% 20.6   0.6   0.6   0.6   0.0
  3. 77.67.77.185  0.0% 29.4   5.2   1.0   9.4   6.0
  4. 77.67.68.118  0.0% 21.2   1.3   1.2   1.3   0.0
  5. 67.14.1.218   0.0% 2   30.6  30.6  30.6  30.6   0.0
  6. 205.171.155.380.0% 2   31.1  30.9  30.8  31.1   0.2
  7. 67.134.58.130 0.0% 2   35.4  35.6  35.4  35.8   0.3
  8. 67.129.132.33 0.0% 2   35.3  35.7  35.3  36.2   0.6
  9. 67.129.132.34 0.0% 2   36.8  36.3  35.8  36.8   0.8
 10. 67.129.132.33 0.0% 2   36.3  35.9  35.6  36.3   0.5
 11. 67.129.132.34 0.0% 2   35.7  36.3  35.7  36.8   0.8
 12. 67.129.132.33 0.0% 2   36.2  36.0  35.8  36.2   0.3
 13. 67.129.132.34 0.0% 2   36.0  36.2  36.0  36.3   0.2
 14. 67.129.132.33 0.0% 2   35.9  35.9  35.8  35.9   0.1
 15. 67.129.132.34 0.0% 2   36.2  36.0  35.8  36.2   0.3
 16. 67.129.132.33 0.0% 2   36.2  36.1  36.0  36.2   0.2
 17. 67.129.132.34 0.0% 2   36.0  36.0  36.0  36.1   0.1
 18. 67.129.132.33 0.0% 2   37.0  36.5  36.1  37.0   0.6
 19. 67.129.132.34 0.0% 2   36.1  37.9  36.1  39.8   2.6
 20. 67.129.132.33 0.0% 2   37.4  37.3  37.3  37.4   0.1
 21. 67.129.132.34 0.0% 2   36.9  39.2  36.9  41.5   3.3
 22. 67.129.132.33 0.0% 2   36.0  36.1  36.0  36.3   0.2
 23. 67.129.132.34 0.0% 2   36.7  36.8  36.7  36.9   0.1
 24. 67.129.132.33 0.0% 2   36.6  36.5  36.4  36.6   0.1
 25. 67.129.132.34 0.0% 2   36.4  36.5  36.4  36.6   0.2
 26. 67.129.132.33 0.0% 2   45.8  41.3  36.8  45.8   6.4
 27. 67.129.132.34 0.0% 2   36.4  36.6  36.4  36.8   0.3
 28. 67.129.132.33 0.0% 2   37.4  38.8  37.4  40.2   2.0
 29. 67.129.132.34 0.0% 2   37.7  38.0  37.7  38.3   0.4
 30. 67.129.132.33 0.0% 2   37.1  37.1  37.1  37.1   0.0
jke...@zao:513 -> whois -h whois.cymru.com " -v 67.129.132.33"
AS  | IP   | BGP Prefix  | CC | Registry | Allocated  | 
AS Name
209 | 67.129.132.33| 67.128.0.0/13   | US | arin | 2002-07-12 | 
ASN-QWEST - Qwest Communications Company, LLC
jke...@zao:514 -> whois -h whois.cymru.com " -v 205.185.95.11"
AS  | IP   | BGP Prefix  | CC | Registry | Allocated  | 
AS Name
209 | 205.185.95.11| 205.185.64.0/19 | US | arin | 2009-07-16 | 
ASN-QWEST - Qwest Communications Company, LLC
jke...@zao:515 ->  

Thanks.

-James



--
James Kelty
Lead Network Engineer
jke...@pandora.com

"The New Jersey Nets are the Detroit Lions of the NBA"
- Max K., Age 12

Re: Addressing plan exercise for our IPv6 course

[Owen DeLong]

On Jul 22, 2010, at 5:37 PM, Matthew Kaufman wrote:

> valdis.kletni...@vt.edu wrote:
>> On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said:
>> 
>>  
>>> I never saw the point of assigning a /48 to a DSL customer. Surely the
>>> better idea would be to assign your bog standard residential DSL
>>> customer a /64 and assign them a /56 or /48 if they request it, routed
>>> to an IP of their choosing.
>>>
>> 
>> If they're using autoconfigure for IPv6 addresses, what happens if they want 
>> to
>> share that connection?  Giving them a /64 off the bat means that a very 
>> sizable
>> fraction of your users are going to call.
>> 
>> Phrased differently - how screwed would you be if you engineered your IPv4
>> network so the default was "one device only", and the customer had to call 
>> you
>> and ask for a network config change because they wanted to hook up a $50 home
>> wifi router?
>> 
>> If it doesn't make sense for IPv4, why would you want to do it for IPv6?
>>  
> "Home wifi router" vendors will do whatever it takes to make this work, so of 
> course in your scenario they simply implement NAT66 (whether or not IETF 
> folks think it is a good idea) however they see fit and nobody calls.
> 
> Matthew Kaufman

Well, wouldn't it be better if the provider simply issued enough space to
make NAT66 unnecessary?

Owen

Re: Addressing plan exercise for our IPv6 course

[Akyol, Bora A]

As long as customers believe that having a NAT router/"firewall" in place is a 
security feature,
I don't think anyone is going to get rid of the NAT box.

In all reality, NAT boxes do work for 99% of customers out there.


Bora


On 7/22/10 7:34 PM, "Owen DeLong"  wrote:


Well, wouldn't it be better if the provider simply issued enough space to
make NAT66 unnecessary?

Owen

Re: Addressing plan exercise for our IPv6 course

[Mark Smith]

On Fri, 23 Jul 2010 00:33:45 +0100
Matthew Walster  wrote:

> On 22 July 2010 14:11, Alex Band  wrote:
> > There are more options, but these two are the most convenient weighing all
> > the up and downsides. Does anyone disagree?
> 
> I never saw the point of assigning a /48 to a DSL customer. Surely the
> better idea would be to assign your bog standard residential DSL
> customer a /64 and assign them a /56 or /48 if they request it, routed
> to an IP of their choosing.
> 

I estimate that an addressing request will cost the ISP at least 15
minutes of time to process. When a minimum allocation of a /32 contains
16 777 216 /56s, do you really need to create that artificial
addressing cost, eventually passed onto the customer?

With more address space than we need, the value we get is addressing
convenience (just like we've had in Ethernet addressing since 1982).
There is no need to make IPv6 addressing artificially precious and as
costly as IPv4 addressing is.

There are a variety of scenarios where customers, including
residential, will benefit from having multiple subnets. They may wish
to separate the wired and wireless segments, to prevent multicast IPTV
from degrading wireless performance. They may wish to segregate the
children/family PC from the adult PC network or SOHO network, allowing
the subnet boundary to be an additional Internet access policy
enforcement point. They'll need separate subnets if they wish to use a
different link layer technology, such as LoWPAN. They may wish to setup
a separate subnet to act as a DMZ for Internet facing devices, such as
a local web server for sharing photos with relatives. Game consoles may
be put in a separate subnet to ensure file transfers don't interfere
with game traffic latency, using the subnet ID as a QoS classifier.


> For the rest of it, I largely agree, though.
> 
> M
> 

Re: Root Zone DNSSEC Deployment Technical Status Update

[Joe Abley]

Hi Leo,

Late reply! Sorry. Have been neglecting this folder.

On 2010-07-16, at 16:53, Leo Bicknell wrote:

> In a message written on Fri, Jul 16, 2010 at 02:35:39PM +, Joe Abley 
> wrote:
>> The transition from Deliberately-Unvalidatable Root Zone (DURZ) to
>> production signed root zone took place on 2010-07-15 at 2050 UTC. The
>> first full production signed root zone had SOA serial 2010071501. There
>> have been no reported harmful effects.  The root zone trust anchor can
>> be found at .
> 
> Perhaps you could explain why the keys are being made available in
> formats that, as far as I can tell, no nameserver software on the
> planet uses?

There seem to be two related issues, here:

1. Why use a format that is non-native to any particular implementation?

We made the decision to publish the trust anchor in a vendor-independent 
fashion. We also wanted a way of publishing a full set of current plus historic 
trust anchors (for which there is no obvious prior art).

The XML representation you've seen has the advantage that precisely because it 
is not in a format directly amenable to cut and paste (although obviously you 
can scrape the RDATA out of it easily; it's just a text file) there's reduced 
risk that someone would paste an old trust anchor into a validator's 
configuration and experience great user hilarity.

We have already seen people produce tools which can process the XML-published 
trust anchor set to configure validators. No doubt we will see more tools in 
future. Maybe some vendors will decide to support it directly.

2. Why publish the trust anchor as a hash of the public key (DS RDATA) rather 
than the public key itself (DNSKEY RDATA)?

Because as far as we can identify, that's the consensus in the relevant IETF 
working groups for how trust anchors should be published. I've heard the 
argument both ways. Don't shoot the messenger.

On a more general note we first published the document which described the 
trust anchor format back in January, and since then we've been soliciting input 
on that (and other documents) in more or less every ops meeting and ops mailing 
list you could mention. We got zero feedback on that document, and perhaps 
unreasonably we interpreted that as a lack of concern over (e.g.) the point you 
mentioned. Here's a link to the final version:

  
http://www.root-dnssec.org/wp-content/uploads/2010/07/draft-icann-dnssec-trust-anchor-01.txt

 
Joe

Re: Addressing plan exercise for our IPv6 course

[Joe Maimon]

Owen DeLong wrote:


On Jul 22, 2010, at 5:37 PM, Matthew Kaufman wrote:


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




If it doesn't make sense for IPv4, why would you want to do it for IPv6?


"Home wifi router" vendors will do whatever it takes to make this work, so of 
course in your scenario they simply implement NAT66 (whether or not IETF folks think it 
is a good idea) however they see fit and nobody calls.

Matthew Kaufman


Well, wouldn't it be better if the provider simply issued enough space to
make NAT66 unnecessary?

Owen



If the only reason the common denominator of internet service has not 
and does not come with more than minimum sufficient supply of IPv4 is 
due to scarcity, then it may be reasonable to hope that in the future 
the common denominator of internet service will include near limitless 
IPv6 addresses for its end users. Very likely, that is better.


However, even then, there is no guarantee that the common denominator 
CPE for this service wont have NAT66 features, maybe even turned on by 
default.


And if those CPE do have the feature on by default, then there is no 
reason for vendors to do more than supply the single /128 or even /64.


Perhaps CPE will respond to a market condition of that nature by 
throwing out /64 subnetting rules and implementing their own 
divide-and-consume addressing scheme. And so it may go on and on. Action 
by action, reaction by reaction, the common scenario evolves, constantly.


Automatic extension of dynamic routing protocols deep into the customers 
network may not be as sound a notion and as universally adoptable as is 
currently viewed.


I believe it is way too early to predict with any confidence how this 
will play out. NAT44 did not become the method-du-jour until well after 
the scarcity was felt by the actual end users of the IPv4 network. Its 
increasing effect on network design and engineering came later yet.


So any addressing plan that does not leave a hefty chunk of space 
reserved to be available for unknown future uses, a la IANA's other /3s, 
strikes me as unable or unwilling to withstand the test of time, by design.


It would be an epic tragedy if down the road those other /3's were 
deemed as unusable as 240/4, maybe even for similar reasons.


I suspect the perfect address plan is the holy grail of networking and 
just as locatable.


Joe

Re: Addressing plan exercise for our IPv6 course

[Mark Smith]

On Thu, 22 Jul 2010 19:53:48 -0700
"Akyol, Bora A"  wrote:

> As long as customers believe that having a NAT router/"firewall" in place is 
> a security feature,
> I don't think anyone is going to get rid of the NAT box.
> 

You need to separate the NAT function (or more specifically, Network
Address Port Translation (NAPT)), and the side effect of that operation
being a deny all for uninitiated inbound traffic. It is not a unique
property to NAPT, and in fact, stateful firewalling using public
addresses has been around as long as NAT (at least since 1995 IIRC).

> In all reality, NAT boxes do work for 99% of customers out there.
> 

So would a firewall with public addressing. It's worked for me for 10+
years with IPv4, and 4+ years with IPv6.

Of course, it didn't protect me when I ran an email attachment that
contained malware, or when I clicked on one of those "PC check"
popups that installed an application. (well, not actually me, but a
large number of people do this, helping the attacker completely bypass
any "NAT security". Inviting the attacker in as though they were a
trusted guest makes the best locks in the world on the door a waste of
time.)

It seems you haven't done much with NAT to have encountered it's
limitations, or experienced the benefits of end-to-end connectivity
(ever had to stuff around with port forwarding, TURN, STUN etc. to get
VoIP working at home? I haven't, and I got to spend that time on
something else much more useful than fiddling with NAT work arounds.)

> 
> Bora
> 
> 
> On 7/22/10 7:34 PM, "Owen DeLong"  wrote:
> 
> 
> Well, wouldn't it be better if the provider simply issued enough space to
> make NAT66 unnecessary?
> 
> Owen
> 
> 
> 
> 

RE: Addressing plan exercise for our IPv6 course

[Frank Bulk - iName.com]

Keep selling them the NAT router, just don't tell them that it applies only
to IPv4 only and not to IPv6.  99.9% of consumers don't know about NAT, they
just want to plug it in and be connected.  That's why having a stateful
firewall as standard element of an IPv6-capable router specification would
keep SOHO IPv6 connectivity "on par" with IPv4.

Frank

-Original Message-
From: Akyol, Bora A [mailto:b...@pnl.gov] 
Sent: Thursday, July 22, 2010 9:54 PM
To: Owen DeLong; matt...@matthew.at
Cc: nanog list
Subject: Re: Addressing plan exercise for our IPv6 course

As long as customers believe that having a NAT router/"firewall" in place is
a security feature,
I don't think anyone is going to get rid of the NAT box.

In all reality, NAT boxes do work for 99% of customers out there.


Bora


On 7/22/10 7:34 PM, "Owen DeLong"  wrote:


Well, wouldn't it be better if the provider simply issued enough space to
make NAT66 unnecessary?

Owen

Re: Addressing plan exercise for our IPv6 course

[Joe Maimon]

Mark Smith wrote:

On Fri, 23 Jul 2010 00:33:45 +0100
Matthew Walster  wrote:


On 22 July 2010 14:11, Alex Band  wrote:

There are more options, but these two are the most convenient weighing all
the up and downsides. Does anyone disagree?


I never saw the point of assigning a /48 to a DSL customer. Surely the
better idea would be to assign your bog standard residential DSL
customer a /64 and assign them a /56 or /48 if they request it, routed
to an IP of their choosing.



I estimate that an addressing request will cost the ISP at least 15
minutes of time to process. When a minimum allocation of a /32 contains
16 777 216 /56s, do you really need to create that artificial
addressing cost, eventually passed onto the customer?


Funny how so much concern is given to eliminating the possibility of end 
users returning for more space, yet for ISP's we have no real concern 
with what will happen when they near depletion of their /32 what with 
/48s to some thousands customers, aggregation, churn, what have you.


The effort and cost of that on the organization is hard to predict, 
especially as how it may vary from size to size, organization to 
organization. Furthermore, everyone else pays with a DFZ slot.


/48 per customer gives the customer as many potential subnets as you 
have potential customers.




With more address space than we need, the value we get is addressing
convenience (just like we've had in Ethernet addressing since 1982).
There is no need to make IPv6 addressing artificially precious and as
costly as IPv4 addressing is.


A balance should be struck and for that to happen, weight must be given 
to both sides.


Joe

Re: Addressing plan exercise for our IPv6 course

[Owen DeLong]

In all reality:

1.  NAT has nothing to do with security. Stateful inspection provides
security, NAT just mangles addresses.

2.  In the places where NAT works, it does so at a terrible cost. It
breaks a number of things, and, applications like Skype are
incredibly more complex pieces of code in order to solve NAT
traversal.

The elimination of NAT is one of the greatest features of IPv6.

Most customers don't know or care what NAT is and wouldn't know the
difference between a NAT firewall and a stateful inspection firewall.

I do think that people will get rid of the NAT box by and large, or, at least
in IPv6, the box won't be NATing.

Whether or not they NAT it, it's still better to give the customer enough
addresses that they don't HAVE to NAT.

Owen

On Jul 22, 2010, at 7:53 PM, Akyol, Bora A wrote:

> As long as customers believe that having a NAT router/"firewall" in place is 
> a security feature,
> I don't think anyone is going to get rid of the NAT box.
> 
> In all reality, NAT boxes do work for 99% of customers out there.
> 
> 
> Bora
> 
> 
> On 7/22/10 7:34 PM, "Owen DeLong"  wrote:
> 
> 
> Well, wouldn't it be better if the provider simply issued enough space to
> make NAT66 unnecessary?
> 
> Owen
> 
> 

Re: Addressing plan exercise for our IPv6 course

[Owen DeLong]

On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote:

> 
> 
> Mark Smith wrote:
>> On Fri, 23 Jul 2010 00:33:45 +0100
>> Matthew Walster  wrote:
>> 
>>> On 22 July 2010 14:11, Alex Band  wrote:
 There are more options, but these two are the most convenient weighing all
 the up and downsides. Does anyone disagree?
>>> 
>>> I never saw the point of assigning a /48 to a DSL customer. Surely the
>>> better idea would be to assign your bog standard residential DSL
>>> customer a /64 and assign them a /56 or /48 if they request it, routed
>>> to an IP of their choosing.
>>> 
>> 
>> I estimate that an addressing request will cost the ISP at least 15
>> minutes of time to process. When a minimum allocation of a /32 contains
>> 16 777 216 /56s, do you really need to create that artificial
>> addressing cost, eventually passed onto the customer?
> 
> Funny how so much concern is given to eliminating the possibility of end 
> users returning for more space, yet for ISP's we have no real concern with 
> what will happen when they near depletion of their /32 what with /48s to some 
> thousands customers, aggregation, churn, what have you.
> 
There's no need to give it a lot of concern because that process is pretty well 
understood and not particularly different from the current process in IPv4.

When an ISP runs out, they apply for more from either their upstream, or, their 
RIR. Just that simple.

> The effort and cost of that on the organization is hard to predict, 
> especially as how it may vary from size to size, organization to 
> organization. Furthermore, everyone else pays with a DFZ slot.
> 
Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much 
smaller than IPv4 that I really find it hard to take this argument seriously.

Additionally, it's not necessarily true due to allocation by bisection.

> /48 per customer gives the customer as many potential subnets as you have 
> potential customers.
> 
You say that like it is a bad thing.

>> 
>> With more address space than we need, the value we get is addressing
>> convenience (just like we've had in Ethernet addressing since 1982).
>> There is no need to make IPv6 addressing artificially precious and as
>> costly as IPv4 addressing is.
> 
> A balance should be struck and for that to happen, weight must be given to 
> both sides.
> 
And it has. /32 is merely the default minimum allocation to an ISP. Larger 
blocks
can be given, and, now that the RIRs are allocating by bisection, it should even
be possible in most cases for that additional space to be an expansion of the
existing allocation without changing the number of prefixes.

e.g. 2001:db8::/32 could be expanded to 2001:db8::/28

16 times as much address space, same number of DFZ slots.

Owen