Re: Comcast IPv6 Update

[Jim Burwell]

On 6/1/2012 11:06, Seth Mattinen wrote:
> On 6/1/12 7:04 AM, Brzozowski, John wrote:
>> Jimmy,
>>
>> Trust me, I work for Comcast and run the IPv6 program.  This has been the
>> case for nearly 7 years.  We can take some of the items below off list.
>>
>> We have launched IPv6 for residential broadband at this time.  Commercial
>> DOCSIS support is later this year.
>>
>> We can do two things.  Get you a residential trial kit so you can have
>> IPv6 for W6L and make sure I have your information for when we start
>> trials for commercial DOCSIS support for IPv6.
>>
>
> Forgive me if this is a stupid question since I've never been a cable
> guy, but what's physical difference between residential and commercial coax?
>
> ~Seth
>
I'm a Comcast biz customer, mostly so I can have static IPs.

I believe the main differences are that biz class has a different group
of people supporting it and provisioning it.  They also use different
CPE.  Probably also use different VLANs and such past the head end.  But
for biz class customers on cable, it uses the same underlying
infrastructure as residential.

I'm mostly speculating here, but I'd think a big hurdle for getting IPv6
service on biz class is in coming up with the
support/provisioning/logistics infrastructure  to support biz customers
with IPv6.  The residential customers have less control over the CPE
than business class, likely making it easier for comcast to make changes
for residential service.  Comcast can update the CPE image, start
running DHCPv6, and voila.  But biz customers routers are somewhat
configurable, and many biz class customers run their own
routers/firewalls behind the comcast CPE (as do some residential
customers also, of course), likely making things more complicated.  I'd
speculate that all the technical pieces are there to do it, but the
logistical/support/management pieces probably aren't ready yet.

Obviously, only the Comcast guys on here (John and Jason) know the whole
story.   But I'm patiently waiting for my native v6!  It'll happen
eventually.   :-)

Re: Comcast IPv6 Update

[Jim Burwell]

On 6/1/2012 12:21, Jared Mauch wrote:
> On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote:
>> On 6/1/12 7:04 AM, Brzozowski, John wrote:
>>> Jimmy,
>>>
>>> Trust me, I work for Comcast and run the IPv6 program.  This has been the
>>> case for nearly 7 years.  We can take some of the items below off list.
>>>
>>> We have launched IPv6 for residential broadband at this time.  Commercial
>>> DOCSIS support is later this year.
>>>
>>> We can do two things.  Get you a residential trial kit so you can have
>>> IPv6 for W6L and make sure I have your information for when we start
>>> trials for commercial DOCSIS support for IPv6.
>>>
>>
>> Forgive me if this is a stupid question since I've never been a cable
>> guy, but what's physical difference between residential and commercial coax?
>   Usually these are terminated on a different CMTS and may use different
> frequencies allocated.
>
>   From a business side, there is a higher SLA afforded to the users,
> including phone notification of planned outages, etc that would happen.
>
>   - Jared
>
Ah I didn't know they even used separate CMTS for the biz customers. 

Re: Comcast IPv6 Milestone

[Jim Burwell]

Congrats to you and your team John!

I presume Comcast Business is still a work in progress?

- Jim

On 7/24/2014 08:08, Brzozowski, John wrote:
> FYI – please feel free to contact me directly if you have any questions:
>
> http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in-launch-of-ipv6-broadband-network
>
> Thank you,
>
> John
> =
> John Jason Brzozowski
> Comcast Cable
> w) www.comcast6.net
> e) john_brzozow...@cable.comcast.com
> =
>
>
>
>

Problems for route to 92.43.96.0/21 for Comcast?

[Jim Burwell]

Can't seem to get to 92.43.96.0/21 (specifically 92.43.96.130 ... in
Salzburg Austria) from Comcast Business in the Bay Area (traceroute
stops close to provider edge).

Works from Verizon FiOS down in LA, and a HE.net host in Fremont.

Comcast folks may want to look at this.  :-)

- Jim

DHCPv6 PD & Routing Questions

[Jim Burwell]

Hi,

Have a simple couple of questions here. 

In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any
reference to the protocol having any role in managing the routing of
prefixes it delegates.  Perhaps I missed it, but I somewhat expected the
omission of this responsibility would be the case.

My questions are:

1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
managing routes to prefixes it delegates, or does it consider this
outside of its function?  (I suspect the latter)
2) What are the most common ways of managing the routing of delegated
prefixes in the ISPs routing domain?  Has a standard method/best
practice emerged yet?  Routing protocols?  IPv6 RAs?

One obvious answer would be routing protocols.  In my brief googling,
I've seen a forum post that seems to indicate that Comcast makes use of
RIPng on their CPE to propagate routing information for prefixes
delegated to it.  Can someone confirm this?  This would seem as good a
method as any to do this, albeit with obvious security concerns.

What's the best way to implement a DHCPV6 PD client on a Linux router? 
Dibbler seems to do everything except route propagation (asks for PD,
puts PD address on local NIC if asked).  Anything better out there?

TIA,
- Jim

Re: DHCPv6 PD & Routing Questions

[Jim Burwell]

On 2015-11-20 15:36, Owen DeLong wrote:
>> On Nov 20, 2015, at 13:35 , Jim Burwell  wrote:
>>
>> Hi,
>>
>> Have a simple couple of questions here. 
>>
>> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any
>> reference to the protocol having any role in managing the routing of
>> prefixes it delegates.  Perhaps I missed it, but I somewhat expected the
>> omission of this responsibility would be the case.
>>
>> My questions are:
>>
>> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
>> managing routes to prefixes it delegates, or does it consider this
>> outside of its function?  (I suspect the latter)
> Yes and no…
>
> DHCPv6 doesn’t include anything specifically per se, but it does require that
> the local router sees the DHCPv6 PD answer in the process of passing it
> along to the target, and there’s a pretty obvious expectation that said router
> will have to arrange to do the needful in that respect.
>
>> 2) What are the most common ways of managing the routing of delegated
>> prefixes in the ISPs routing domain?  Has a standard method/best
>> practice emerged yet?  Routing protocols?  IPv6 RAs?
> RAs really only apply to subnet local advertisement of routers and
> the on-net prefixes in most implementations.
>
> I don’t think any of the various methods of using routing protocols,
> static pre-routed blocks from which PDs are delegated, etc.  could
> necessarily be called “standardized”, but there are probably a few
> that are more popular than most of the others.
>
> Unfortunately, PD is really still in its infancy in terms of development
> and real running code for complete implementations throughout any
> sort of site hierarchy.
>
> Owen
>
>

On 2015-11-20 15:36, Owen DeLong wrote:
>> On Nov 20, 2015, at 13:35 , Jim Burwell  wrote:
>>
>> Hi,
>>
>> Have a simple couple of questions here. 
>>
>> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any
>> reference to the protocol having any role in managing the routing of
>> prefixes it delegates.  Perhaps I missed it, but I somewhat expected the
>> omission of this responsibility would be the case.
>>
>> My questions are:
>>
>> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for
>> managing routes to prefixes it delegates, or does it consider this
>> outside of its function?  (I suspect the latter)
> Yes and no…
>
> DHCPv6 doesn’t include anything specifically per se, but it does require that
> the local router sees the DHCPv6 PD answer in the process of passing it
> along to the target, and there’s a pretty obvious expectation that said router
> will have to arrange to do the needful in that respect.
>
>> 2) What are the most common ways of managing the routing of delegated
>> prefixes in the ISPs routing domain?  Has a standard method/best
>> practice emerged yet?  Routing protocols?  IPv6 RAs?
> RAs really only apply to subnet local advertisement of routers and
> the on-net prefixes in most implementations.
>
> I don’t think any of the various methods of using routing protocols,
> static pre-routed blocks from which PDs are delegated, etc.  could
> necessarily be called “standardized”, but there are probably a few
> that are more popular than most of the others.
>
> Unfortunately, PD is really still in its infancy in terms of development
> and real running code for complete implementations throughout any
> sort of site hierarchy.
>
> Owen
>
>
Thanks for the answer Owen!

So it sounds like things are still in flux.  But it least it answers my
main question of "have I missed something here"?

Could you elaborate on the "local router seeing the PD answer" a bit?  I
presume by "local router" you mean router acting as DHCPv6 relay?  Or do
you mean the router which made the original request?

Would it be fair to say that the RFCs only really talk about delegating
the prefixes, and leave what to do with the prefixes themselves up to
the implementer?

I'm asking these questions because I'm doing a little class for some
folks on IPv6 and this is one area where I couldn't find answers. 

- Jim

Re: DHCPv6 PD & Routing Questions

[Jim Burwell]

On 2015-11-21 05:08, Dave Taht wrote:
> y'all might want to look over the work of the ietf homenet working
> group for some insight into plans for dhcp-pd, and routing
> interactions, in the home and small business, at least.
>
> https://tools.ietf.org/wg/homenet/
>
> some dhcpv6 specific info is spread around using the new hncp protocol.
>
> blatant plug - https://github.com/sbyx/odhcp6c is now the best open
> source dhcpv6 (and pd) client "out there" right now IMHO.
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Sat, Nov 21, 2015 at 11:13 AM, Frederik Kriewitz
>  wrote:
>> On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell  wrote:
>>> 2) What are the most common ways of managing the routing of delegated
>>> prefixes in the ISPs routing domain?  Has a standard method/best
>>> practice emerged yet?  Routing protocols?  IPv6 RAs?
>>>
>>> One obvious answer would be routing protocols.  In my brief googling,
>>> I've seen a forum post that seems to indicate that Comcast makes use of
>>> RIPng on their CPE to propagate routing information for prefixes
>>> delegated to it.  Can someone confirm this?  This would seem as good a
>>> method as any to do this, albeit with obvious security concerns.
>> We've build a small tool which watches the dhcpd6 lease file for
>> changes and injects the PD routes using exabgp (iBGP session with
>> corresponding IA_NA address as next-hop for the IA_PD prefix).
>>
>> Best Regards,
>> Frederik Kriewitz
Thanks for all the replies.

The gist I get is that no real SOP/BCP has emerged yet for doing this,
and everyone is home-brewing their own methods.

One of the other reasons I ask is because I was experimenting with
Comcast Business IPv6.  I was sent a cable modem that could do
dual-stack and did PD.  But it seemed really broken.  It would only
assign a /64, and never routed anything it assigned back to the head end
as far as I could see through the customer interface.  I was told that
the firmware was broken.

- Jim

Re: Comcast IPv6 Update

[Jim Burwell]

On 11/9/2011 08:58, Livingood, Jason wrote:

On 11/9/11 11:54 AM, "Blake T. Pfankuch"  wrote:



This appears directed at the Home market.  Any word on the Business Class
market even as a /128?

Business Class is coming later. It won't hurt to contact the Business
Class sales number and ask about IPv6 (and tell them to escalate it) - it
all helps get us internal support and buy in. It is definitely on our
radar though.

- Jason


Yeh.  I've been waiting since before the trial started for biz class 
IPv6.  I even read some article on one of the Comcast sites (IIRC) that 
one of their business class customers was doing NDS.  I guess it was a 
one-off.  :)

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

On 1/14/2010 11:10, Cameron Byrne wrote:
> Folks,
>
> My question to the community is:  assuming a network based IPv6 to IP4
> translator is in place (like NAT64 / DNS64), are IPv6-only Internet
> services viable as a product today?  In particular, would it be
> appropriate for a 3G /smartphone or wireless broadband focused on at
> casual (web and email) Internet users?  Keep in mind, these users have
> NAT44 today.
>   
You may also want to read up on Dual Stack Lite (DS-Lite)
,
presuming you haven't.  I know you mentioned you didn't like any
dual-stack solutions, but the thing about DS-Lite I like is that it has
no problem with RFC1918 overlap of different customers, since the CGN
uses a tunnel ID in the connection/NAT table in addition to the other
typical data.  I just wonder how it will scale, since each device, or a
gateway the device goes though, will require a IPv4-in-IPv6 tunnel to
the CGN box(es).  Also, it doesn't require a DNS-ALG like NAT64/DNS64.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

Sorry for late response here...

On 1/14/2010 15:20, Cameron Byrne wrote:
> On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell  wrote:
>   
>> On 1/14/2010 11:10, Cameron Byrne wrote:
>> 
>>> Folks,
>>>
>>> My question to the community is:  assuming a network based IPv6 to IP4
>>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet
>>> services viable as a product today?  In particular, would it be
>>> appropriate for a 3G /smartphone or wireless broadband focused on at
>>> casual (web and email) Internet users?  Keep in mind, these users have
>>> NAT44 today.
>>>
>>>   
>> You may also want to read up on Dual Stack Lite (DS-Lite)
>> <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02>,
>> 
> I have looked at DS-lite very carefully.   First, DS-Lite fits better
> for cable operators since they have CPE and can have a DS-lite
> function in the CPE that they control, and that in turn allows them to
> provide IPv4, IPv6, and dual-stack to the end-host that they do not
> control.  DS-Lite does not fit as well for a mobile phones since it
> would require a major change to the phone's OS.  Second, DS-Lite
> requires tunneling as well as translation, so it is one more piece of
> overhead in addition to NAT64 solution.  For me, i believe it is less
> complex to manage a single stack IPv6 host with NAT64 translation than
> a dual stack host, tunneling infrastructure, as well as NAT44 CGN,
> which is what DS-lite requires.  They both achieve the same result,
> but I believe in the mobile space there is a quicker time to market as
> well as more progress toward the end-goal of IPv6-only using NAT64
> than DS-lite.
>   
I guess the choice here is between standing up and managing a NAT64 CGN
+ special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite
tunneling infrastructure (you'd be able to keep existing "vanilla" DNS
servers).

Presuming you could set up DS-Lite capable routers somewhere in the
path, one nice thing about DS-Lite would be that you could allow a mix
of dual-stack phones, IPv4 only phones, and even DS-Lite capable phones
on the same network.  This could be an advantage if IPv6 stacks or
DS-Lite virtual nic/tunnel drivers weren't available on all customer
phones.  Also, as Mr. Durand mentioned earlier, DS-Lite has an advantage
in application compatibility too. 

And, admittedly getting a bit speculative here, by virtue of the fact
that a DS-Lite solution would give each phone an IPv4 address, "NAT
compatibility" of various applications may also be better on the CGN,
since NAT44 is so well understood and generally "worked out" today,
where a NAT64 CGN might not support as many "problem apps" which require
"fixups" as a DS-lite NAT44 CGN.

But if we can presume all phones will have IPv6, and all applications
running on them are IPv6 capable, then DNS64/NAT64 would in some ways be
cleaner, since it'd eliminate the traffic overhead of tunneling, etc. 
You'd just have to stand up and manage the DNS64 servers and NAT64 CGNs.

>> presuming you haven't.  I know you mentioned you didn't like any
>> dual-stack solutions, but the thing about DS-Lite I like is that it has
>> no problem with RFC1918 overlap of different customers, since the CGN
>> uses a tunnel ID in the connection/NAT table in addition to the other
>> typical data.  I just wonder how it will scale, since each device, or a
>> gateway the device goes though, will require a IPv4-in-IPv6 tunnel to
>> the CGN box(es).  Also, it doesn't require a DNS-ALG like NAT64/DNS64.
>> 
> NAT64/DNS64 does not use a DNS-ALG.  DNS-ALG died with NAT-PT.  DNS64
> is a standalone function which is decoupled from the translation
> process.
>   
Yeah this is improper terminology I suppose.  I use "DNS-ALG" in the
IPv6 transition context as a generic term for any specialized DNS server
which hacks IPv4 addresses into fake IPv6 addresses for these sorts of
purposes, which is further overloading the term I guess. :p  Not sure
what to use as a better generic term for this.

The point I was trying to make is that DS-Lite doesn't require any DNS
hackery, unlike NAT64/DNS64, for what it's worth.

Anyway, plenty to weigh/consider here.

PS:  Nice to see the author of the DS-Lite drafts participating here
too.  :)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

On 1/15/2010 23:45, Owen DeLong wrote:
>
> On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote:
>
>> Sorry for late response here...
>>
>> On 1/14/2010 15:20, Cameron Byrne wrote:
>>> On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell >> <mailto:j...@jsbc.cc>> wrote:
>>>
>>>> On 1/14/2010 11:10, Cameron Byrne wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> My question to the community is:  assuming a network based IPv6 to IP4
>>>>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet
>>>>> services viable as a product today?  In particular, would it be
>>>>> appropriate for a 3G /smartphone or wireless broadband focused on at
>>>>> casual (web and email) Internet users?  Keep in mind, these users have
>>>>> NAT44 today.
>>>>>
>>>>>
>>>> You may also want to read up on Dual Stack Lite (DS-Lite)
>>>> <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02>,
>>>>
>>> I have looked at DS-lite very carefully.   First, DS-Lite fits better
>>> for cable operators since they have CPE and can have a DS-lite
>>> function in the CPE that they control, and that in turn allows them to
>>> provide IPv4, IPv6, and dual-stack to the end-host that they do not
>>> control.  DS-Lite does not fit as well for a mobile phones since it
>>> would require a major change to the phone's OS.  Second, DS-Lite
>>> requires tunneling as well as translation, so it is one more piece of
>>> overhead in addition to NAT64 solution.  For me, i believe it is less
>>> complex to manage a single stack IPv6 host with NAT64 translation than
>>> a dual stack host, tunneling infrastructure, as well as NAT44 CGN,
>>> which is what DS-lite requires.  They both achieve the same result,
>>> but I believe in the mobile space there is a quicker time to market as
>>> well as more progress toward the end-goal of IPv6-only using NAT64
>>> than DS-lite.
>>>
>> I guess the choice here is between standing up and managing a NAT64 CGN
>> + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite
>> tunneling infrastructure (you'd be able to keep existing "vanilla" DNS
>> servers).
>>
>>
> As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable
> device
> without any modification.  The DS-Lite Gateway does all the heavy lifting
> to provide IPv4 services and do the NAT64 translation between the
> IPv6-only
> end-user device (phone) and the IPv4 internet.
>
Could well be the case.  My idea was that you could do it either way. 
You could have a DS-Lite gateway (Typical.  Likely built into the "cable
modem" or similar device), or in the case where no gateway is available,
a DS-Lite "client" (basically a virtual nic/tunnel driver) on the
machine would establish the tunnel and an IPv4 address itself.  But
perhaps this latter method was never intended?


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

On 1/16/2010 07:01, Antonio Querubin wrote:
> On Sat, 16 Jan 2010, Cam Byrne wrote:
>
>> interested you can read the ietf draft.  Assuming you have a ds-lite
>> cpe, you can park dual-stack hosts behind it.  But, it does not "just
>
> If your hosts are dual-stacked, why would you need a ds-lite cpe in
> the first place?
>
The point of DS-Lite is to provide IPv4 internet access to hosts which
only have IPv6 addresses in an IPv6 only network environment.  That is,
IPv4 connectivity isn't available all the way through to the provider's
CGN.  If you did straight dual-stack, the provider would have to do IPv4
connectivity all the way to the CGN, and also maintain unique RFC1918 IP
address assignments to every customer going through a particular CGN. 
With DS-Lite, the IPv4 traffic is tunneled from a DS-Lite router
fronting the customer's LAN, or from a host itself (a presumption)
running some sort of DS-Lite driver.  Because the traffic can by
identified by the CGN from the tunnel it came in on, the RFC1918s don't
have to be unique (the customer can pick whatever he wants for his/her
LAN).  A full DS network isn't needed throughout the entire provider
infrastructure, hence the name DS "Lite". 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using /126 for IPv6 router links

[Jim Burwell]

On 1/25/2010 20:06, Mark Smith wrote:
>
> This from people who can probably do decimal to binary conversion
> and back again for IPv4 subnetting in their head and are proud of
> it. Surely IPv6 hex to binary and back again can be the new party
> trick? :-)
>
>
>   
Hehe.  Decimal -> binary in your head?  I don't even bother except if
it's some well known "magic #s".  Hex -> binary though is super simple
since unlike decimal, each digit translates exactly into a nybble.  You
just have to know the binary from 0 - 15, 16 simple four-bit patterns,
and it's a piece of cake.  You can give me hex numbers and and I'll
rattle off binary all day, or vica-versa.  Octal is similarly easy, but
would result in some long IPv6 addresses.  :-)



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using /126 for IPv6 router links

[Jim Burwell]

On 1/26/2010 23:32, Mark Smith wrote:
>
> A minor data point to this, Linux looks to be implementing the
> subnet-router anycast address when IPv6 forwarding is enabled, as it's
> specifying Solicited-Node multicast address membership for the
> all zeros node address in it's MLD announcements when an interface
> comes up.
>
>   
Yes, I believe you are correct.  It appears to be implemented.  When I
ping the subnet anycast from a Linux or Windows XP box I get a reply
from the IPv6 router on my LAN.  The router is a Linux box running
Kernel 2.6.31.  Interestingly, on a Linux box, the ping6 command shows
the router's unicast address answering the pings (same goes for ping6
under Cygwin on a Windows box).  But on a Windows box ping shows the
anycast address answering.  However, in both cases packet captures show
it actually is the unicast address of the router answering, which I
believe is the expected behavior.  Windows ping just shows the wrong
address for whatever reason.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IP4 Space - the lie

[Jim Burwell]

On 3/5/2010 06:38, Cameron Byrne wrote:
> There is one of other catch with NAT64 and IPv6-only. It breaks
> communications with IPv4 literals.  Now, you might says that IPv4
> literals in URLs are very seldom well ... have a look at how
> Akamai does a lot of their streaming.  I just hope it does not come to
> a show-down where networks move to IPv6-only since IPv4 is a goner and
> now Akamai content is not available while IPv6 early adopters like
> Google and Limelight laugh all the way to bank.
>
One of the reasons I like the idea of DS-Lite.  It may not be as
native-IPv6 pure-and-holy as NAT64/DNS64, but it allows end users, IPv4
only applications, and legacy/non-IPv6 equipment to actually use IPv4
addresses.  When the end user's favorite application stops working, or
he can't play games online with his Xbox 360, he won't care about any
explanations of NAT64/DNS64, or whose fault it is.  He'll just want
things to work.  DS-Lite still allows this, and doesn't have any real
impact on IPv4 exhaustion, since the end user will be issued RFC1918s,
(likely) overlapped with other end users' RFC1918s.

I also speculate that if one takes a large user community, say,
customers of an ISP, and put them on NAT64/DNS64, we'll likely discover
a lot more "IPv4 only" applications/services/appliances out there than
we were expecting via the explosive ringing of flooded help desk lines.  :p

Granted, DS approaches will slow native IPv6 adoption a bit, but I think
the real-world alternative is chaos.  I personally prefer a scenario
where users can go on using the internet as they've always done, likely
oblivious to whether any particular site or application is using IPv6 or
IPv4, while "behind the curtain" these same sites/applications are
switching over to native IPv6, than a scenario where things simply stop
working for them.

Also, I hope that any pain associated with going through a CGN used in
any of these sorts of approaches, and/or the benefits of native IPv6,
will speed native IPv6 adoption more than any transition method might
slow it.  One can hope. :p

Re: IP4 Space

[Jim Burwell]

On 3/10/2010 05:06, Andy Koch wrote:
> On Wed, Mar 10, 2010 at 04:55, Jens Link  wrote:
>   
>> Owen DeLong  writes:
>>
>> 
 denial
 anger
 bargaining
 depression
 
>>> acceptance<--- My dual-stacked network and I are here.
>>>   
>> So am I. But most IT people I talk to are still at the denial phase. And
>> there is not much one can do about it.
>> 
Denial, incredulity, and even anger have often been the reaction I get
from IT people when I bring up IPv4 exhaustion and IPv6.  I'm careful to
try to be "cool" about it too, trying not to be preachy or annoying
about it.

Some recent samples of IT people I talk to regularly in IRC:

> sam:  Basically. We've had ipv6 for how many years in the UNIX world
> and we STILL haven't switched yet ...
> Ken:   only Jim cares about IPv6
> sam:  15 years of hype and we might get to it in another 5
> sam:  Emphasis on might
> sam:  Everything I've installed in the last 2 years has ipv6 disabled
> Ken:   i finally got an email from comcast about my participating in
> their ipv6 trials ... haha ... TRIALS - they're still at least 2 years
> out i'm sure
I doubt I'm the only one who's run across these sorts of attitudes.  At
least Ken is willing to participate in the Comcast trial.  :)

IMHO, only personally experienced pain is going to push a lot of these
sorts of people into ipv6.  By pain, I mean things such as not being
able to deploy their new service (web site, email server, VPN box,
whatever) on the internet due to lack of ipv4 addresses, having to
implement double NAT, CGN/LSN, or being forced to live behind such an
arrangement ["what do you mean I can't port forward the port for my
favorite game/new service?!?!" (yes, I know some schemes will still
allow customer port forwards, but this will be made more difficult,
painful, since many users will now be sharing the same publics.)] 

Once the "pain" hits, many will be doing crash courses in ipv6 and
rolling it out as quickly as they can.  I think it's just human nature.  :)

- Jim

Re: IP4 Space

[Jim Burwell]

On 3/10/2010 16:57, Owen DeLong wrote:
>>
>> IMHO, only personally experienced pain is going to push a lot of these
>> sorts of people into ipv6.  By pain, I mean things such as not being
>> able to deploy their new service (web site, email server, VPN box,
>> whatever) on the internet due to lack of ipv4 addresses, having to
>> implement double NAT, CGN/LSN, or being forced to live behind such an
>> arrangement ["what do you mean I can't port forward the port for my
>> favorite game/new service?!?!" (yes, I know some schemes will still
>> allow customer port forwards, but this will be made more difficult,
>> painful, since many users will now be sharing the same publics.)]
>>
>> Once the "pain" hits, many will be doing crash courses in ipv6 and
>> rolling it out as quickly as they can.  I think it's just human
>> nature.  :)
>>
>> - Jim
>>
>>
>
8<---
>
> I try to avoid being preachy, but, at the same time, there are some
> pretty hard numbers available. It's not the guys on IRC that need
> the most convincing anyway.  They know, and in many cases,
> while they're still in denial, they don't need to change because
> they couldn't get support from above if they did.
>
> The target really needs to be the CxOs and the management,
> especially in places where there is content facing the general
> public.  Fortunately, Google, Yahoo, Netflix, etc. get it and have
> moved forward with IPv6. Some others are coming along.
True.  CxOs can basically order it to be done.  But for the "guys in the
trenches", I often talk about the issues just to give them a heads up,
so they don't get caught off guard when ipv4 exhaustion hits.

Plus, they can also exert pressure upwards that can cause decisions to
be made.  And in the case of small shops and start ups, they often are
the primary decision makers/influencers for all things IT anyway (a
situation I'm very familiar with).

8<---
> The main thing we need to convey to our colleagues in the IRC
> crowd is that IPv6 really isn't as difficult as some have made
> it out to be.  While it does require some different thinking, mostly
> in the area of address planning, the rest of it is pretty much
> business as usual just like IPv4.
>
> The other hurdle I've encountered is fear about "switching" to
> IPv6. We need to be clear that we aren't "switching" to IPv6,
> we're "adding IPv6 capabilities to the existing IPv4 network".
> The former creates a lot more fear of change than the latter.
Yep.  I always try to convey how similar everything is for day to day
network operations.  I try to tell them that if they understand IPv4
CIDR, subnetting, etc, they're already 3/4 of the way there for IPv6. 
IMHO, address planning for the average company is far simpler under
IPv6.  Typically they'll be given a /48, and then they'll have 64Ki /64s
to use for subnets, and that's it, and often all they'll ever need.  To
me this is simpler than the typical assortment of RFC1918s with heavy
VLSM.  Not to mention the RFC1918 overlap complications that arise with
partnerships, mergers, etc.  :-)

Yes.  I always emphasize dual-stack too.  I tell them to just give it a
try by setting up, say, an HE tunnel to one machine.  Then later
terminate the tunnel to a router and try it on a few more boxes. 
Another thing I do if they're running Vista or Windows 7, is to ping an
IPv6 address, and when Teredo gets them ping replies, I tell them "see,
you're already running IPv6 and have basic connectivity".  Although I
don't know if this is a good idea, since Teredo isn't the most reliable
thing.  :p

> Owen
>
> (Oh, and in case anyone doesn't know, yes, I work for Hurricane
> Electric. I went to work there because I liked what they were doing
> with IPv6. I'd recommend their products (and did) even if I did not
> work there.)
>
I get my IPv6 over an HE 6in4 tunnel.  :-)

I wish my ISP (who shall remain unnamed) provided native IPv6 service,
but this is the response I got last time I inquired:

> Unfortunately, we don't have a status on changing to IPv6. We currently offer 
> only ADSL2, Fiber and T1.
And then after a second inquiry about a few months later:

> We are aware of the IPv4 situation and at this point and time we have no
> plans to switch over to IPv6. 
A shame since I'm otherwise very pleased with this ISP.  I may hit them up 
again since it's been nearly a year since the last inquiry.  Or at least try to 
get through to someone other than a TSE or a Billing & Collections Manager.  :)

Re: New Linksys CPE, IPv6 ?

[Jim Burwell]

FWIW, I see no IPv6 options on my WRT610N HW Version 2.  I thought maybe
there was a new firmware version which added IPv6 capability, but I'm
still running the latest.  There's no IPv6 options on any menu,
including 6to4 options that I can see.  May be available under DD-WRT or
something similar, although last time I looked this model only had alpha
stage support for DD-WRT.

- Jim

On 3/31/2010 14:51, Frank Bulk - iName.com wrote:
> I confirmed with Linksys' PR person that there is no IPv6 -- if someone sees 
> different, please let us know.
>
> Frank
>
> -Original Message-
> From: Joel Jaeggli [mailto:joe...@bogus.com] 
> Sent: Wednesday, March 31, 2010 4:30 PM
> To: frnk...@iname.com
> Cc: 'Nick Hilliard'; NANOG
> Subject: Re: New Linksys CPE, IPv6 ?
>
> It's not in the wrt610n docs either yet the code was unambiguously in
> the box, complete with 6to4 that your couldn't shut off.
>
> On 03/31/2010 01:26 PM, Frank Bulk - iName.com wrote:
>   
>> I checked the documentation for two models (Linux model and highest-end 
>> non-Linux model), and there's no mention of IPv6.
>>
>> Frank
>>
>> -Original Message-
>> From: Nick Hilliard [mailto:n...@foobar.org] 
>> Sent: Wednesday, March 31, 2010 3:16 PM
>> To: Joel Jaeggli
>> Cc: NANOG
>> Subject: Re: New Linksys CPE, IPv6 ?
>>
>> On 31/03/2010 21:07, Joel Jaeggli wrote:
>> 
>>> the current wrt610n supports ipv6  I failed to see why a slightly
>>> updated and rebranded one would not as well.
>>>   
>> because for low-end CPE devices like this, a tiny change in the model
>> number (e.g. v1->v2) might mean a completely different internal system,
>> with different host CPU, different ethernet controller, etc.  You're not in
>> any way guaranteed the same sort of software compatibility when moving from
>> one device version to another, particularly for less well supported
>> features like ipv6.
>>
>> Nick
>>
>>
>> 
>
>   




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Important: IPv4 Future Allocation Concept RFC

[Jim Burwell]

On 4/1/2010 15:41, Joe Greco wrote:
> Someone suggested this be posted more visibly.
>
> ... JG
>   
LOL




smime.p7s
Description: S/MIME Cryptographic Signature

Re: legacy /8

[Jim Burwell]

On 4/2/2010 17:22, Randy Bush wrote:
> ipv4 spae is not 'running out.'  the rirs are running out of a free
> resource which they then rent to us.  breaks my little black heart.
>
> even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a
> lng while.  when 95% of the world has end-to-end ipv6, do you think
> amazon et alia are gonna blow 5% of their market by decomissioning ipv4?
>
> we are gonna learn how to distribute and use ipv4 more efficiently.
> it's not that hard, we know how to do it.  internet engineers have
> worked through and around a lot of problems, it's our job.  making
> connectivity continue work for folk who, for whatever reason, delay
> migration from ipv4 is just part of our job.  not to panic.
>
> the hard part is figuring out how the rirs make money off ipv4 holders
> redistributing it among themselves.  if that becomes a non-goal, things
> get a lot simpler.
>   
So, jump through hoops to kludge up IPv4 so it continues to provide
address space for new allocations through multiple levels of NAT (or
whatever), and buy a bit more time, or jump through the hoops required
to deploy IPv6 and eliminate the exhaustion problem?  And also, if the
IPv4 space is horse-traded among RIRs and customers as you allude to
above, IPv6 will look even more attactive as the price and preciousness
of IPv4 addresses increases.

The idea isn't for IPv4 to be replaced (decommissioned).  The idea is
for IPv6 to be added, then things will slowly transition.  IPv4 will be
around for a long time indeed, but increasingly, new sites/services, and
old sites/services will be adding IPv6 as a way to connect to them. 
Then at some point, IPv6 will become the "normal" way to connect, and
IPv4 will be a the "legacy" way, with fewer and fewer using it.

Also, reading your other post, if you don't understand the difference
between 2^32 and 2^128, please start here: 
http://en.wikipedia.org/wiki/Exponential_growth

Anyway, I see it as pretty much moot, since many major players (Comcast,
Google, etc) are in the midst of major IPv6 deployments as we speak. 
Eventually you will have to jump on the bandwagon too.  :-)

- Jim

Re: legacy /8

[Jim Burwell]

On 4/2/2010 19:13, George Bonser wrote:
>
>   
>> -Original Message-----
>> From: Jim Burwell [mailto:j...@jsbc.cc]
>> Sent: Friday, April 02, 2010 6:00 PM
>> To: nanog@nanog.org
>> Subject: Re: legacy /8
>> 
>
>   
>> So, jump through hoops to kludge up IPv4 so it continues to provide
>> address space for new allocations through multiple levels of NAT (or
>> whatever), and buy a bit more time, or jump through the hoops required
>> to deploy IPv6 and eliminate the exhaustion problem?  And also, if the
>> IPv4 space is horse-traded among RIRs and customers as you allude to
>> above, IPv6 will look even more attactive as the price and
>> 
> preciousness
>   
>> of IPv4 addresses increases.
>> 
> No problem,  everyone tunnels v4 in v4 and the "outer" ip address is
> your 32-bit ASN and you get an entire /0 of "legacy" ip space inside
> your ASN.  Just need to get rid of BGP and go to some sort of label
> switching with the border routers having an ASN to upstream label table
> and there ya go. Oh, and probably create an AA RR in DNS that is in
> ASN:x.x.x.x format.  Increase the MTU a little and whammo!  There ya go!
> Done.
>
> :)
>
>   
So essentially add 32-bits to the IPv4 address, used as a ASN, and use
legacy V4 on the "backbone" which tunnels everything, so the entire
intra-ASN internet has to go through v4-in-v4 tunnels.  A few "little"
changes to DNS, and voila!  And of course, there's no "devils in the
details" we have to worry about.  Heck.Just quote that last post up
and submit it as an RFC to replace the IPv6 RFCs!  :-)

Seriously though, would that really be easier to implement, or be better
than IPv6 as this point?  I'd think the IETF would probably have
considered solutions like that, but IPv6 is what we got.  So best learn
to love it.  :P

-Jim




smime.p7s
Description: S/MIME Cryptographic Signature

Re: legacy /8

[Jim Burwell]

On 4/2/2010 21:23, Randy Bush wrote:
>> Anyway, I see it as pretty much moot, since many major players (Comcast,
>> Google, etc) are in the midst of major IPv6 deployments as we speak. 
>> Eventually you will have to jump on the bandwagon too.  :-)
>> 
> clue0: the isp for which i work deployed ipv6 in the '90s.  we were the
>world's first commercial ipv6 isp deployment.
>   

> clue1: not only can i do the math, but i can remember history
>   
Heh.  I didn't really doubt that you understood the math.  Was just
being a bit snarky.  :p  (this whole thread is sort of flame bait anyway
hehe).

Anyway, with just 2000::/3 alone, there's about 500 million /32s. 
According to the CIDR report, there's ~34,000 ASs in BGP right now. 
Lets double that "for future growth" just for fun.  If we do that, it
means if we divided those /32s evenly among all of those ASes, each
would get about 7800 of them.  Each one contains 64Ki /48s.  And again,
that's just one /3 of the entire v6 space (yeah I know they won't be
divided evenly ... different sizes orgs, regional assignments, etc, etc,
etc).

Anyway, I think the addy space will tide us over for quite a while, even
if it's "not enough" as your last post seemed to indicate.  Hey, and if
we ever do run out, we can just NAT!  ;) ;) ;)

-Jim

Re: legacy /8

[Jim Burwell]

On 4/3/2010 01:03, Jeroen van Aart wrote:
> Owen DeLong wrote:
>> It was thought that we would not have nearly so many people connected
>> to the internet.  It was expected that most things connecting to the
>> internet would be minicomputers and mainframes.
>
> It took some visionary and creative thinking to "come up" with the
> internet. But given such a train of thought the idea of everyone being
> connected isn't such a wild idea. I can imagine it'd be almost a given.
>
> Although if I get the time frame right in those days you had 2 camps,
> those (ibm, dec...) who believed that there was no need for home
> computers and you only needed a few (hundred?) thousand big mainframes
> and minicomputers and those (commodore, apple...) who believed
> (rightfully so) there was going to be a big future and demand for home
> computers.
>
> So I guess depending on what "camp" you were in, it's not that strange
> to not envision all these household computers being interconnected.
>
Hindsight is always 20/20.  But remember that the internet started as a
DoD project with just the military, mil contractors, universities, etc,
connected to it.  At first it wasn't even envisioned as something the
general public would even use.  And back in those times having a
computer at home was still a fairly unusual thing.  Only "geeks" had
them (I remember kids poking fun at me back in middle school when they
found out I had a home computer).  Back then, during the "computer
revolution", you used a modem to connect to BBSes, services like
Compu$serve, and perhaps the UUCP network for email and usenet.  The
internet was something only big orgs, corps, universities, and the
military had.

So it's not *too* surprising that the "explosion" that happened after
the web browser/server came into being was a bit of a surprise for
people.  And it wasn't all that long after the explosion that I started
hearing about things like "IP-NG", etc (for a while I thought IPv6 would
use OSI NSAPs hehe).  So they got busy addressing the problem pretty
quickly, despite having not predicted such a big explosion in internet
use.  Of course my memory could be a bit foggy, but there are guys on
this list who were on the leading edge of all this who could (and
probably have) tell the whole story in more detail.  :)

-Jim

Re: what about 48 bits?

[Jim Burwell]

On 4/4/2010 08:46, Jonathan Lassoff wrote:
> Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010:
>   
>> On Sun, 4 Apr 2010 11:10:56 -0400
>> David Andersen  wrote:
>>
>> 
>>> There are some classical cases of assigning the same MAC address to every 
>>> machine in a batch, resetting the counter used to number them, etc.;  
>>> unless shown otherwise, these are likely to be errors, not accidental 
>>> collisions.
>>>
>>>   -Dave
>>>
>>> On Apr 4, 2010, at 10:57 AM, jim deleskie wrote:
>>>
>>>   
 I've seen duplicate addresses in the wild in the past, I assume there
 is some amount of reuse, even though they are suppose to be unique.

 -jim

 On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr.  wrote:
 
> Hi,
>
> Lots of traffic recently about 64 bits being too short or too long.
>
> What about mac addresses? Aren't they close to exhaustion? Should be. Or 
> it
> is assumed that mac addresses are being widely reused throughout the 
> world?
> All those low cost switches and wifi adapters DO use unique mac addresses?
>
>   
>> Sun, for one, used to assign the same MAC address to every NIC in the
>> same box.
>> 
> I could see how that *could* work as long as each interface connected to
> a different LAN.
>   
That was a logic Sun used.  Every NIC would be connected to a different
subnet, so duplicate MACs shouldn't be a problem.  For the most part
this worked, but some situations required a unique MAC per NIC, and Sun
had a bit you could flip to turn this on.  I believe it was an OpenBoot
prom variable called "local-mac-address?" which you'd set to true if you
wanted it to use each NICs MAC instead of the "system MAC".

-Jim

Re: What is "The Internet" TCP/IP or UNIX-to-UNIX ?

[Jim Burwell]

On 4/4/2010 12:18, Steven Bellovin wrote:
> On Apr 4, 2010, at 3:08 16PM, Lyndon Nerenberg wrote:
>
>   
>>> File transfer wasn't multihop
>>>   
>> It was, for at least some versions (V2 and later?), if the intermediate 
>> site(s) allowed execution of the uucp command. 25 years on the brain is 
>> fuzzy on the details ...
>> 
>
> You could certainly add uux and uux to the list of legal remote commands, but 
> I confess that my memory is also dim about whether
>
>   uucp file a!b!c
>
> would be translated automatically.  It has indeed been a while...
>   
Heh this brings back some memories.  uucp/uux for email and news.  I
remember writing shells scripts that would pull the UUCP maps out of the
UseNet newsgroup (comp.mail.maps IIRC) and run "pathalias" on it to
generate email bang path routes to all other mapped UUCP sites from
yours so that you could use domain-style email addresses instead of
remembering the paths! 

So then you could address an email to "u...@uucpsite.uucp" and Sendmail
or Smail (I ran Smail) would look it up in the pathalias generated
databse and convert it to a bang path.  :)

I also remember a few key "dual-connected" sites which were both on the
UUCP network and the internet were used as gateways into the
internet/DNS/SMTP email world.  Specifically I remember "psuvax" being a
widely used, and abused site for this, which eventually shut down that
service because too many people were using them as a UUCP/internet
gateway for email, sucking up all their cycles and bandwidth!

-Jim

Re: What is "The Internet" TCP/IP or UNIX-to-UNIX ?

[Jim Burwell]

On 4/4/2010 17:20, Barry Shein wrote:
> I still believe that had as much to do with the collapse of the Soviet
> Union as the million other politicians who wish to take credit.
>
> It's arguable that UUCP (and Usenet, email, etc that it carried) was
> one of the most powerful forces for change in modern history. All you
> needed was some freely available software, a very modest computer, a
> modem, a phone line, and like so many things in life, a friend.
>
> And then once you "got it", you looked towards connecting to the
> "real" internet, you knew just what you were after.
>
>   
I agree.  I remember back in the 80s when I first got access to UseNet
and UUCP based email thinking and saying things like "the net will
change the world", because for the first time people from all over the
globe were communicating fairly openly and inexpensively, and somehow
the internet and UUCP seemed to come in "under the radar" back then.  I
had more than a few people scoff at me for thinking that way though.  :-)

Re: what about 48 bits?

[Jim Burwell]

On 4/4/2010 19:16, Mark Smith wrote:
<-snip->
> Actually the IEEE have never called it "Ethernet", it's all been IEEE
> 802.3 / XXX{BASE|BROAD}-BLAH.
>
> "Ethernet", assuming version 1 and 2, strictly means thick coax, vampire
> taps and AUI connectors running at (half-duplex) 10Mbps. I saw some of
> it once.
>   
I worked with it at my first job at a large government institution. 
Talk about painful and unweildy.  We had parts of our network wired with
10base5 (thick ethernet) with vampire taps, and had some segments wired
with transceivers which had a pair of threaded "type N connectors" (not
sure if this is the proper name ... it's what my boss called them ...
looked like oversized CATV F connectors).   The xceiver boxes were
pretty big (4-5 inches wide) and connected to the node via an AUI  drop
cable.

The N connectors were easier to deal with than the vampire taps.  To add
a node, you just "spliced" a new xceiver box onto the line where you
needed it by screwing a new length of cable into the new + existng
xceivers, then connecting the AUI drop cable from the box to the node.

Eventually we went to 10base2 (thin ethernet) and then like everyone
else, 10baseT hubs. 

Re: BGP hijack from 23724 -> 4134 China?

[Jim Burwell]

On 4/9/2010 15:42, Benjamin Billon wrote:
>
>>> This is also blocking Sina, Netease, Yahoo.cn and other major
>>> Chinese ISP/ESP. Am I the only to think this is not very smart?
>>
>> It depends. I'am not a fan of country blocking. But in my case it can
>> work for a home server. You could adapt the list and block port 22
>> only for production servers where you can't expect to never have
>> email from China, but can safely block brute force ssh attacks.
>>
> Yep, home server, your server. That's not the same when you have
> customers who rely on your server.
> IMHO, port 22 and other critical ports should always be blocked except
> from known places.
>
I personally use a port knocking setup and it pretty much eliminates SSH
brute force account/password hacks.  Actually, on one box that didn't
have the ability to do that, I simply moved the SSH port.  This was
surprisingly effective, although a bit inconvenient. 

I'll have to say that a very large number of the brute attempts were
from Chinese IPs.  Hopefully they're not reading this.  ;-)

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/21/2010 03:38, Mark Smith wrote:
> On Tue, 20 Apr 2010 21:16:10 -0700 Owen DeLong 
> wrote:
>
>>>
>>> Frankly, when you hear people strongly using the argument
>>> stateful firewalling == NAT, you start to wonder if they've
>>> ever seen a stateful firewall using public addresses.
>>>
>> I've run several of them.
>>
>
> My comment wasn't a reply to you, more of a general comment about
> the surprising effort you still need to go to explain that
> stateful firewalling doesn't mandate NAT.
>
> I sometimes wonder if some people's heads would explode if I told
> them that this PC is directly attached to the Internet, has both
> public IPv4 and IPv6 addresses, and is performing stateful
> firewalling - with no NAT anywhere.
>
I hear ya.  Except for simple translations (e.g. one-to-one, whole net
xlates), NAT is dependent on SPI, but SPI is not dependent on NAT.
But some seem to combine the two into a single inseparable concept.
I've definitely run into people who confuse the concepts.  And also
presume that without NAT there is less or no security.

This head definitely wouldn't explode, since back in the early to mid
90s I ran enterprise networks on which all hosts had public IPs and
there was no NAT at all.  First protected by "dumb filters" on
routers, which were fairly quickly replaced by dedicated SPI firewalls
(such as Checkpoint).  The first couple SPI firewalls I used didn't
even *have* NAT capability.  Yet, they did a fine job securing my LANs
without it.  And this is at a time when most workstations and servers
on the LAN didn't have firewalls themselves (no OS included FW).

Despite it doing the job it was intended to do, I've always seen NAT
as a bit of an ugly hack, with potential to get even uglier with LSN
and multi-level NAT in the future.  I personally welcome a return to a
NAT-less world with IPv6.  :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvO87cACgkQ2fXFxl4S7sSzQQCfU4Ip5mHkJ/inTfKO/1zih5yY
VWUAnjte4aAbrcYvUraMXsUmaPj2JHGA
=S3Gn
-END PGP SIGNATURE-

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/22/2010 05:34, Simon Perreault wrote:
> On 2010-04-22 07:18, William Herrin wrote:
>> On the other hand, I could swear I've seen a draft where the PC
>> picks up random unused addresses in the lower 64 for each new
>> outbound connection for anonymity purposes.
>
> That's probably RFC 4941. It's available in pretty much all
> operating systems. I don't think there's any IPR issue to be afraid
> of.
>
> Simon
I think this is different.  They're talking about using a new IPv6 for
each connection.  RFC4941 just changes it over time IIRC.  IMHO that's
still pretty good privacy, at least on par with a NATed IPv4 from the
outside perspective, especially if you rotated through temporary IPv6s
fairly frequently.

Of course, for browsers, as someone else mentioned, it's somewhat moot
because of cookies.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvQR1IACgkQ2fXFxl4S7sT0agCglqjxX9d2kYuadrreIqPo5+rN
FMAAniW1GodHwArieT/Czd96aMGQTgEF
=xYjP
-END PGP SIGNATURE-

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/22/2010 22:00, Owen DeLong wrote:
>
> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 4/22/2010 05:34, Simon Perreault wrote:
>>> On 2010-04-22 07:18, William Herrin wrote:
>>>> On the other hand, I could swear I've seen a draft where the
>>>> PC picks up random unused addresses in the lower 64 for each
>>>> new outbound connection for anonymity purposes.
>>>
>>> That's probably RFC 4941. It's available in pretty much all
>>> operating systems. I don't think there's any IPR issue to be
>>> afraid of.
>>>
>>> Simon
>> I think this is different.  They're talking about using a new
>> IPv6 for each connection.  RFC4941 just changes it over time
>> IIRC.  IMHO that's still pretty good privacy, at least on par
>> with a NATed IPv4 from the outside perspective, especially if you
>> rotated through temporary IPv6s fairly frequently.
>
> 4941 specified changing over time as one possibility.  It does
> allow for per flow or any other host based determination of when it
> needs a new address.
>
> Owen
K.  Can't say I've read the RFC all the way through (skimmed it).
Current implementations do the time thing.  XP, Vista, and 7 seem to
have it turned on by default.  *nix has support via the
"net.ipv6.conf.all.use_tempaddr=2" variable, typically not on by default.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvRLkUACgkQ2fXFxl4S7sQ2YgCg3uSkp1GNxcgjCDVc1jxnDv7s
DtoAniXH8nND7+r6xEFJXGHrRJ77CBkZ
=eSHI
-END PGP SIGNATURE-

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/22/2010 22:18, Matthew Kaufman wrote:
> Owen DeLong wrote:
>> On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote:
>>
>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 4/22/2010 05:34, Simon Perreault wrote:
>>>
>>>> On 2010-04-22 07:18, William Herrin wrote:
>>>>
>>>>> On the other hand, I could swear I've seen a draft where
>>>>> the PC picks up random unused addresses in the lower 64 for
>>>>> each new outbound connection for anonymity purposes.
>>>>>
>>>> That's probably RFC 4941. It's available in pretty much all
>>>> operating systems. I don't think there's any IPR issue to be
>>>> afraid of.
>>>>
>>>> Simon
>>>>
>>> I think this is different.  They're talking about using a new
>>> IPv6 for each connection.  RFC4941 just changes it over time
>>> IIRC.  IMHO that's still pretty good privacy, at least on par
>>> with a NATed IPv4 from the outside perspective, especially if
>>> you rotated through temporary IPv6s fairly frequently.
>>>
>>
>> 4941 specified changing over time as one possibility.  It does
>> allow for per flow or any other host based determination of when
>> it needs a new address.
>>
>> Owen
>>
>>
>>
> But none of this does what NAT does for a big enterprise, which is
> to *hide internal topology*. Yes, addressing the privacy concerns
> that come from using lower-64-bits-derived-from-MAC-address is
> required, but it is also necessary (for some organizations) to
> make it impossible to tell that this host is on the same subnet as
> that other host, as that would expose information like which host
> you might want to attack in order to get access to the financial
> or medical records, as well as whether or not the executive floor
> is where these interesting website hits came from.
>
> Matthew Kaufman
Yeh that information leak is one reason I can think of for supporting
NAT for IPv6.  One of the inherent security issues with unique
addresses I suppose.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvRMCsACgkQ2fXFxl4S7sShwACgpZEd1rQD+/+dxonkOVpwPaUj
oBIAoOJ78A5Yvftfz+JPjGWWQoVhb6F8
=oQHv
-END PGP SIGNATURE-

Re: Connectivity to an IPv6-only site

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/23/2010 05:42, Jared Mauch wrote:
>
> On Apr 23, 2010, at 5:49 AM, Dave Hart wrote:
>
>> On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand
>>  wrote:
>>> - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the
>>> authoritative name servers
>>>
>>> - both of these servers *only* have IPv6 addresses
>>
>> Which seems a bit far afield from reality to me.  Yes, there are
>> lots of folks with IPv6 connectivity and v4-only recursive DNS
>> servers.  I don't think ISPs will have problems setting aside a
>> handful of IPv4 addresses for authoritative DNS infrastructure to
>> work around this until v6 transport in recursive DNS servers is
>> common enough.
>
> Not really, having your nameservers be IPv6 enabled is a reasonable
> thing to do.
>
> FYI: on comcast I see SERVFAIL, meaning their recursives do not
> have IPv6 transport.
>
> (I know we have that at my employer on our customer-facing
> recursives).
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> any www.onlyv6.com. ;; global
> options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
> SERVFAIL, id: 54773 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,
> AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION: ;www.onlyv6.com.INANY
>
> ;; Query time: 1605 msec ;; SERVER: 68.87.72.130#53(68.87.72.130)
> ;; WHEN: Fri Apr 23 08:41:08 2010 ;; MSG SIZE  rcvd: 32
>
>
You'll see a lot of this.  I've done my own little tests on a few
friends' systems, and on public wifi, etc, establishing some sort of
IPv6 connectivity, and trying to resolve a subdomaiin of mine with a
IPv6 only DNS server.  Many ISP recursive NS don't have IPv6 transport
yet, so they choke getting to my NS.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvRnmUACgkQ2fXFxl4S7sTfJwCfaKEB8juoXkHsgX7N+F+HNrEC
PDwAoJm+Hn8NhBi6LKcX00T9JTEA35ma
=nzM5
-END PGP SIGNATURE-

Re: Rate of growth on IPv6 not fast enough?

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/23/2010 06:17, Clue Store wrote:
>
>
>> But none of this does what NAT does for a big enterprise, which
>> is to *hide internal topology*. Yes, addressing the privacy
>> concerns that come from using
>> lower-64-bits-derived-from-MAC-address is required, but it is
>> also necessary (for some organizations) to make it impossible to
>> tell that this host is on the same subnet as that other host, as
>> that would expose information like which host you might want to
>> attack in order to get access to the financial or medical
>> records, as well as whether or not the executive floor is where
>> these interesting website hits came from.
>>
>> Matthew Kaufman
>
>> Yeh that information leak is one reason I can think of for
>> supporting NAT for IPv6.  One of the inherent security issues
>> with unique addresses I suppose.
>
> 
>
> What makes you think that not using NAT exposes internal
> topology?? I have many cases where either filtering at layer-2 or
> NAT'ing a /48 for itself (or proxy-arp for those that do not have
> kits that can NAT IP blocks as itself) does NOT expose internal
> topology. Get your filtering correctly setup, and there is no use
> for NAT/PAT in v6.
>
> NAT was designed with one puropose in mind . extending the
> life of v4... period! The so called security that most think NAT
> gives them is a side effect. NAT/PAT also breaks several protocols
> (PASV FTP, H.323, etc) and I for one will be happy to see it go. I
> think it's a mistake to include NAT in v6 because there are other
> methodologies of accomplishing all of the side effects that
> everyone is use to seeing NAT provide without having to actually
> translate IP's or ports.
>
> I for one (as well as alot of other folks I know) am not/will not
> be using any kind of NAT moving forward.
>
> 
I'm not really advocating NAT for v6.  I'm just saying it's one valid
security issue with using any sort of globally unique IP address (v4
or v6), in that analyzing a bunch of traffic from a particular
netblock would allow one to build a topology map.  It's easier with
IPv6 since you can presume most if not all addresses are on  /64s out
of a /48 (so look to the fourth quad for the "subnet ID").

Obviously if someone is super concerned with revealing this sort of
info there are other things besides NAT they can do, such as using a
proxy server(s) for various internet applications, transparent
proxies, etc.  But it is a valid security concern for some.

Also, is that your real name?  ;-)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvRozwACgkQ2fXFxl4S7sSACQCfeRfk5VmKjkW2SYkn/gZl53Ng
Q0cAoKsQTGdTTBaEg1paE44yTNVy2OSQ
=WAPA
-END PGP SIGNATURE-

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 4/26/2010 03:36, Mikael Abrahamsson wrote:
> On Sun, 25 Apr 2010, Owen DeLong wrote:
>
>> I fail to see how link local is any more difficult than any
>> other IPv6 address.
>
> They're different because you have to know your local network
> interface name as well.
>
>> Windows might get interesting as windows interface naming is,
>> uh, creative at best.
>
> Exactly.
>
Installation software could make this easy.  It could either prompt
the user to type in the address on a sticker then enumerate all
interfaces on the system and attempt to contact the router on each NIC.

Another possibility is that it could enumerate all the interfaces,
then use the IPv6 link-local scope all routers multicast (ff02::2) to
enumerate a list of routers found on each link, sort them and/or
filter them by ethernet OUI, and present a list of choices for the
user to click on to configure the router.  The user could also easily
match the enet address on a little slip of paper or sticker on the
router to this list, or through some initial settings on the router
which allow info to be pulled from it somehow, present a list of
unconfigured routers, etc, etc.

Point is, I can imagine a lot of ways this could be made user-proof
via software/firmware combination that requires no advanced networking
knowledge.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvVpywACgkQ2fXFxl4S7sSCuwCg07Gwxz6NDYuTkVYr5gP5LUMC
n4EAoIdqZQ7C/01X0EcV3vnZiTD4b7Vc
=hDQN
-END PGP SIGNATURE-

Re: Internationalized domain names in the root

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 5/7/2010 22:53, Peter Beckman wrote:
> On Fri, 7 May 2010, Jeroen van Aart wrote:
>
>> David Conrad wrote:
>>> Perhaps a bit off-topic, but some folks might get support calls...
>>>
>>> http://وزارة-الأتصالات.مصر/
>>
>> That actually looks quite handsome. :-)
>
>  And this is what it looks like to DNS:
>
>  http://xn--4gbrim.xnrmckbbajlc6dj7bxne2c.xn--wgbh1c/
>
>  Hurrah for Punycode.
Yeah I was experimenting around with that yesterday.  Imagine a zone
file full of such domain names.  Ack!  "Did I accidentally hit x in
the middle of that name in VIM?  Better run it through the converter
to make sure."  Yay yet another level of complexity in DNS
management.  Some of the names look as ugly as the contents of DNSSEC
RRs.  :-)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkvluX8ACgkQ2fXFxl4S7sTghwCg8sh1ZrKpa3d/GlYaGYhAZKN+
/HEAmgPrKZaaHynHRQuTAYfe4xQAWIh1
=cO/L
-END PGP SIGNATURE-

Re: useful bgp example

[Jim Burwell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 5/19/2010 11:58, Dan White wrote:
> You should be using 192.168.2.0 for documented examples,or at least
> private
> space. Configs like this tend to get cut and pasted into routers and
> get
> changed only when they don't work.
Should that be 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24
(TEST-NET-3) per RFC 5737  ?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkv0R4UACgkQ2fXFxl4S7sScDACgulmdHhk6QJX/OlfvP1cCMq2e
TZcAoIgrbd9HPFjpoSJvRFbML8VgckKj
=zKse
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 Training

[Jim Burwell]

On 12/23/2009 13:03, Mike Leber wrote:
>
> Marty Anstey wrote:
>> Just wondering if anyone has had any experience with IPv6 training
>> courses.
>>
>> A quick search turns up a few results on the subject, but it would be
>> handy to hear if anyone has any firsthand experiences or
>> recommendations.
>> We're based in western Canada but don't mind traveling a bit, but
>> alternatively an online course would be acceptable as well.
>
> Once you have IPv6 connectivity established (either native IPv6 or via
> a tunnel from anybody (for example tunnelbroker.net or sixxs.net) if
> you want a self teaching procedural guide where you can setup and test
> various IPv6 services (HTTP, SMTP, reverse DNS, forward DNS, host
> record glue) then you might checkout our free IPv6 certification
> service at:
>
> http://ipv6.he.net/certification
>
> It's a bit tongue in cheek and meant to be sort of like entertainment
> with education for engineers (for example the certification ranks are
> from "Newb" to "Sage").  By the time you are done you are done IPv6
> won't seem weird.  (In fact, you'll probably be thinking "that's it?!")
>
Tongue in cheek?  You mean I'm not *really* a Sage?  :p :p

The tunnelbroker.net forum is also a good source of info/discussion
about IPv6.  It'd be nice if it was a bit more "active" though.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

[Jim Burwell]

On 1/6/2010 01:23, Dobbins, Roland wrote:
> On Jan 6, 2010, at 4:18 PM, Matthew Palmer wrote:
>
>   
>> The closest I can come to a solution is to set a random password and flash 
>> it using a front-panel LED using morse.  
>> 
> heh
>
> No password at all, operator prompted at the console during startup 
> unless/until he sets one.  No IP address, et. al. until a password is set.
>   
Yeah.  And for devices with no console, only network interfaces, a
default IP address, no default password, and no default route (just in
case they plug it into a real LAN instead of a laptop.  :p  ).