Re: Ipv6 for the content provider

[Antonio Querubin]

On Wed, 26 Jan 2011, Owen DeLong wrote:


It's actually pretty well known and it is documented in several places in plain
sight.


Where?

A search for IPV6_V6ONLY in the FreeBSD Handbook yields nothing.  You'd 
think the brokenness would at least be mentioned in the handbook.


A similar search of the FreeBSD FAQ yields a bunch of hits but none that 
really mention the RFC brokenness.


The only place where I've seen this behaviour mentioned in the past is in 
bug reports.  And the responses to those were that the non-compliant 
behaviour was preferred but would/should be more clearly documented. 
Years later, the documentation is still lacking.


Antonio Querubin
e-mail/xmpp:  t...@lava.net

RE: PPPOE vs DHCP

[Frank Bulk]

We were a mostly PPPoA shop, and were doing PPPoE on our FTTH but moved to
DHCP because of our desire to move to v6 without waiting for the access
vendor and to get rid of supporting that username/password combo.  And DSL
modems that we're replacing in the field we're moving from PPPoA to PPPoE
because of Ethernet transport because I'm not as sold on RBE in a 7206VXR,
even though I really could use the same Option 82 in the same way as we do
for FTTH.

VLAN-per-user seems like a lot of router config overhead, though I could be
proved wrong if I misunderstand.

Frank

-Original Message-
From: Paul Stewart [mailto:p...@paulstewart.org] 
Sent: Tuesday, January 25, 2011 6:34 PM
To: nanog@nanog.org
Subject: PPPOE vs DHCP

Hey folks...

I'm meeting with a customer tomorrow (service provider, rural telco) and
we're pitching they move to a PPPOE platform most likely.  But to be fair,
I'm looking to draw up a comparison so they are "well informed" of the
pros/cons.  Has anyone done this?

RE: PPPOE vs DHCP

[Frank Bulk]

By IA_TA support, do you mean the ability for the 7206VXR to act as the DHCPv6 
server?  If I understand you correctly, I have it working well with DHCPv6 
relay.

Frank

-Original Message-
From: Jack Bates [mailto:jba...@brightok.net] 
Sent: Wednesday, January 26, 2011 12:04 PM
To: nanog@nanog.org
Subject: Re: PPPOE vs DHCP


On 1/26/2011 11:03 AM, Tim Franklin wrote:
> So they're telling us, at least for PPPoE specifically.  Cisco solution is 
> "buy ASR".
>

This is same solution they've given for the 7206 and other traditional 
IOS platforms. I haven't checked, but all the RBE/unnumbered vlan 
support for IPv6 with proxy-ND, better radius backend for DHCPv6, and 
supposedly IA_TA support for DHCPv6 will be in the ASR only. The 
features in IOS SR train are somewhat functional but extremely limited.

If I find myself having to spend money on ASRs, I may just spend the 
money replacing them with Juniper. Only reason I haven't is that I 
haven't needed to spend the money at all.

Jack

RE: PPPOE vs DHCP

[Frank Bulk]

If Cisco won't do a good job of RBE on the 7206VXR, I may just need to stick 
with PPPoEv6 on the SR train.  I have that successfully working in a test bed.

Frank

-Original Message-
From: Jack Bates [mailto:jba...@brightok.net] 
Sent: Wednesday, January 26, 2011 12:04 PM
To: nanog@nanog.org
Subject: Re: PPPOE vs DHCP


On 1/26/2011 11:03 AM, Tim Franklin wrote:
> So they're telling us, at least for PPPoE specifically.  Cisco solution is 
> "buy ASR".
>

This is same solution they've given for the 7206 and other traditional 
IOS platforms. I haven't checked, but all the RBE/unnumbered vlan 
support for IPv6 with proxy-ND, better radius backend for DHCPv6, and 
supposedly IA_TA support for DHCPv6 will be in the ASR only. The 
features in IOS SR train are somewhat functional but extremely limited.

If I find myself having to spend money on ASRs, I may just spend the 
money replacing them with Juniper. Only reason I haven't is that I 
haven't needed to spend the money at all.

Jack

RE: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Frank Bulk]

Have you looked at D-Link's DIR-825?  It has most of the things you're
looking for.  The DIR-655 is a more affordable option.

In regards to (2), is it even possible to do DHCPv6-PD on with a SLAAC WAN?

In regards to (3), I have that working on SRE, but with an external DHCP
server.

Frank

-Original Message-
From: Jack Bates [mailto:jba...@brightok.net] 
Sent: Wednesday, January 26, 2011 11:59 AM
To: Owen DeLong
Cc: nanog@nanog.org
Subject: Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

I believe it has to do with IPv6 mechanisms for handling native 
addressing. I haven't had the opportunity to test it myself, but from 
dealing with other vendors, I find that they all support subsets of 
possible configurations. For example, we test the following with each 
CPE device which supports IPv6 and is up for consideration.

1) 6to4 support
2) SLAAC + DHCPv6-PD on bridging wan (haven't found one yet, and I 
believe still the only setup for IOS)
3) DHCPv6 IA_TA requests + DHCPv6-PD (too bad IOS SR doesn't support 
this yet?)
4) Support of RA to determine default route (seen many require manual 
gateway configurations since DHCPv6 won't send a default router option)
5) PPPoE/A with above combinations
6) PPPoE/A unnumbered ptp + DHCPv6-PD
7) /60 and /48 DHCPv6-PD and how they are assigned by the CPE
8) DHCPv6 IA_TA, SLAAC, and DHCPv6-PD support on the device's LAN and 
determining the mechanism it uses
9) Default stateful firewall rules for IPv6.
10) Support for static assignments and routing for IPv6 (many devices 
are still working on dynamic support and have no manual support)

I've yet to find a consumer grade product which meets all of these 
different configurations; especially in the $50 range.


Jack

On 1/26/2011 11:01 AM, Owen DeLong wrote:
> I haven't done exhaustive testing, but, it has to do with certain
combinations
> of IPv4 configurations and IPv6 routing do work and other combinations
> don't.
>
> Owen
>
> On Jan 26, 2011, at 4:41 AM, Richard Barnes wrote:
>
>> Could you elaborate?  Which circumstances?
>>
>> On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong  wrote:
>>> It works for routing native IPv6 under some circumstances as well.
>>>
>>> Owen
>>>
>>> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote:
>>>



 On Wed, 26 Jan 2011, Franck Martin wrote:

> What about an Airport Extreme? It has a wan interface that does PPPOE
>
> The IPv6 feature seems working, with 6to4 or static tunnels and a
basic IPv6 firewall.

 Yes it is. I already reported to Marco.
 http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey

 It should be included somehow in a matrix But 6to4 (or other tunneling
techniques) is only a substitute of real IPv6.

 Regards,
Janos Mohacsi

>
> - Original Message -
> From: "Mirjam Kuehne"
> To: nanog@nanog.org
> Sent: Tuesday, 25 January, 2011 3:34:14 AM
> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input
Needed
>
> [apologies for duplicates]
>
> Hello,
>
> Based on new information we received since the last publication, we
> updated the IPv6 CPE matrix:
>
>
http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
>
> In order to make this information more useful for a large user base,
we
> are preparing a detailed survey to gather more structural feedback
about
> the range of equipment that is currently in use. Not only would we
like
> you to participate in this survey, but we also ask for your help in
> identifying the right survey questions. Please find a call for input
on
> RIPE Labs:
>
>
http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-
needed
>
> Kind Regards,
> Mirjam Kuehne&  Marco Hogewoning
> RIPE NCC
>
>
>
>>>
>>>
>>>
>
>

RE: What's the current state of major access networks in North America ipv6 delivery status?

[Frank Bulk]

All the leading MSOs are actively working towards IPv6 trials and
deployments, they're just at different stages.  Comcast, as we all can see,
is publicly leading, but there are others who are not too far behind.

Frank

-Original Message-
From: Antonio Querubin [mailto:t...@lava.net] 
Sent: Wednesday, January 26, 2011 5:09 PM
To: Charles N Wyble
Cc: nanog@nanog.org
Subject: Re: What's the current state of major access networks in North
America ipv6 delivery status?

On Wed, 26 Jan 2011, Charles N Wyble wrote:

> How about TimeWarnerCable? They don't seem to have any sort of v6
> offering, on wholesale or retail services.

TW Cable has no IPv6 offering.

However, TW Telecom provides IPv6 connectivity upon request.  By default 
they only provide a /56 if you need multiple subnets and you have to 
provide further justification to get a /48.


Antonio Querubin
e-mail/xmpp:  t...@lava.net

Re: Another v6 question

[Roland Dobbins]

On Jan 27, 2011, at 1:29 PM, Owen DeLong wrote:

> I'm saying that in IPv6, we've put enough addresses in to allow for things 
> nobody has thought of in 30, 60, 90, even 100 years and then some.

Possibly, as long as we don't blow through them via exercises in profligacy 
nobody has heretofore thought of, heh.

;>


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

RE: What's the current state of major access networks in North America ipv6 delivery status?

[Frank Bulk]

Two good lists are here:
http://www.sixxs.net/faq/connectivity/?faq=native
http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers

Frank

-Original Message-
From: Charles N Wyble [mailto:char...@knownelement.com] 
Sent: Wednesday, January 26, 2011 3:52 PM
To: nanog@nanog.org
Subject: What's the current state of major access networks in North America
ipv6 delivery status?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is anyone tracking the major consumer/business class access networks
delivery of ipv6 in North America?

I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
looked into 6rd. Is this a dead end path/giant hack?

https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco
nf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0

I spoke with impulse.net last year, which appears to serve large
portions of the AT&T cable plant in Southern California. They were
willing to offer native ipv6. Not sure how (one /64, a /48) etc.

I see that FiOS did a trial in April 2010
http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-tes
ting-ipv6.html
(it mentions special CPE). What about verizon DSL?

Comcast is currently conducting trials:
http://comcast6.net/ (anyone participated in this?)

How about TimeWarnerCable? They don't seem to have any sort of v6
offering, on wholesale or retail services.

Am I missing anyone in the DSL/Cable/FTTH market?

As for wireless broadband providers, there is satellite and 3g/4g/LTE. I
haven't looked at the satellite providers. I know Verizon is offering
dual stack on their LTE service, according to a thread a couple weeks
ago.  T-mobile is offering it on the small subset of phones that have v6
capable baseband.

For grins and giggles, how does North America stack up against other
regions, when it comes to access network ipv6 delivery.

Thanks.

- -- 
Charles N Wyble (char...@knownelement.com)
Systems craftsman for the stars
http://www.knownelement.com
Mobile: 626 539 4344
Office: 310 929 8793
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNQJd/AAoJEMvvG/TyLEAtIx4P/1ehNtwotF30HZf4BqeWlJ7C
gGmp33VkvwPdh8qUT4scHT/Wcql2V/ijhEJk7t0Tu9F98ig51c3euLuJ9iUhgP8v
RdX9Ty8uAThs2EL/sT3aEVlrbiEOtkjW5zFQzWv3So7aPFeO9u5uBa9XO2eeOFG4
nI1ztpPzq3obGGLZWixIJ3ukOvKnb1ilKk74h9kjvnRA89wE1nS8ZvulWdWovAZ6
CaiU54SARQFlqtZ5PsrPrAi1LEz5lXP3Pp3kvphjp019XmyPvtgFwqwX6WoMbBgQ
hHulUEnTX9A/3S/Llzz/eQRcWDX+KtqfF/khNBglsr6Y8tBgvJ360YI7dmn9J2hS
1QmnkiwTKlSkvbBM9HVbC/no7nB/J4ybOTVV004ciY6WWTRnCNGtgnoUWO4+qJVK
E0996B2egOmhkUJs8AR+VYsguEVbSc12wbxZYrfjTjh7yE87q92okw/mUVi5OOVL
t+ysZpV6yifR6/0T26VTJnJ/Ha6tjOE8SmA6lSKdKac5GTPkFBRqzkqsgGmF3lQq
NAYMaVKmmq58j5e3eA8btGNf/u4wzJv9JJFXx3aij7pCE29yAfSrMfNV8r6ayAvL
lDXQH3AP6LpV6EPb2vAUPq95iw+Fvl5PN80PYdyxVwpphQRutYQYvPZBh9/RfFOi
LL5HLupKb900MQX/ZMjY
=tE8q
-END PGP SIGNATURE-

RE: What's the current state of major access networks in North America ipv6 delivery status?

[Frank Bulk]

This is all hearsay, but I learned from a shared vendor that AT&T is putting
pressure on them to complete their IPv6 support, so that the vendor is
moving up completion from Q4 to Q2.  This was a sales person talking, so who
knows.

Frank

-Original Message-
From: Charles N Wyble [mailto:char...@knownelement.com] 
Sent: Wednesday, January 26, 2011 4:33 PM
To: nanog@nanog.org
Subject: Re: What's the current state of major access networks in North
America ipv6 delivery status?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/26/2011 01:52 PM, Charles N Wyble wrote:
> 
> Is anyone tracking the major consumer/business class access networks
> delivery of ipv6 in North America?
> 
> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
> looked into 6rd. Is this a dead end path/giant hack?
> 
>
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco
nf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
> 

Found an article talking about at&t v6 support

http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3

Also found
http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNQKEzAAoJEMvvG/TyLEAt45cP/0g+8lNUb1z6Ew/tWgGPEYWu
u7wemSTjs27yxKXIbdfWzcWizvX3THHFNW6oRlRIdaH3z+Ttkzb/ne5wEDw9lcgV
vnW0n/QjKQOWFaZ+chgEpplEVPth5jww/B/o9taeS7MXonbhQipTeTo3/U7am0GB
MCZXngLllOhPZmmjhqsssiLX94wjc5uvqSdAExTt7aXQ7+SaVzpFghXTZgWAG9eE
X9JpFeLhJMNPed1MOzxOn7WTsqDu2sHyszoyrZwGyjyQ/JZFDFfdhE3qQPRe97tv
ZOmlfPYFjJRjQ4MlY7iX+BI/CTRAeM+59oslpX8h7VeGY4zmlNGw8dhR1yvB400h
w+/GubudSnL50XppUslKWbl03v+4dTQYMy3dotwH2OM8ovcJMn596rLW8j+3zV7t
zcOuLSLFlqY6QZYy8tp705qzYesLWvHJJlpbXryyOGoz/5SJyTvfkDywOgyNeXz4
siU2a+JaAxlJsrBc9YsabCY8C60zFQxKBwANXWhvP7TZiFtt+SaNLp/Eahh9NoAO
Zygs4FekumT9TFeNsAnPlHFFCl9v6fU0Yxc8u0ffYa2+hW6f/2My4tY0n07PNd8l
DUUO7h9GtLpfEgTk2eLavY8HZcb1RtA4cvMe8n1J2GOVCwpGfOD0xl1Y3AX6v+rk
JuGqPIfyQ8GiNtj7KzRV
=LASk
-END PGP SIGNATURE-

Re: Another v6 question

[Owen DeLong]

On Jan 26, 2011, at 9:31 PM, Max Pierson wrote:

> >V4 30 years ago -- expected consumption: ~60 /8s of 256.
> >IPv6 today -- expected consumption: Maybe 15 /12s of 4096.
> >The scales in question are vastly different.
> 
> I made no such comparison between the two. The scales are vastly different, 
> but I think you're still missing my point. 30 years ago, no one "expected" 
> cells phones to consume IP's. 30 years ago, no one "expected" xbox's and 
> playstations to consume IP's. Point being is the "unexpected".
> 
I'm not missing your point. I'm saying that in IPv6, we've put enough addresses
in to allow for things nobody has thought of in 30, 60, 90, even 100 years and
then some.

> >Not at all... In my opinion, IPv6 will probably last about 30-50 years. In 
> >my opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I 
> >>absolutely think we'll have to do this all again. I just don't think that 
> >addresses are going to be the thing we run out of next time.
> 
> Ok then, what is it exactly you think we'll run out of in 30-50 years?? 
> Please elaborate.
> 
If I knew, then, I'd be well on my way to much greater wealth. Whatever it is, 
I am only
certain of the following things about it:

1.  We have no idea what the requirements will be at this time.
2.  We have no idea which particular scaling limit in IPv6 will 
actually drive
us to the next protocol.
3.  Our needs in 30-50 years will be different than our needs today.
4.  This all assumes that we have a human race to care about having 
an
internet in 50 years. Such is not necessarily a safe assumption.

> >No, that's not what I said at all. What I said was that addressing isn't 
> >going to be the constraint that causes us to have to revamp it next time.
> 
> Once again, please elaborate.
> 
See below... I pretty much did elaborate in another message about
the number of /48s and the construction rate required to consume
them.. I don't know what will cause us to
revamp it next time. I'm just sure there are enough numbers to make
it to that point.

> >The point was that if you're trying to figure out how big routers are
> >going to have to be for near-term IPv6 or even medium-term IPv6
> >deployment, counting the total possible number of prefixes isn't
> >a useful metric because the actual utilization will be nowhere
> >near that large and the numbers are impossible to use as an
> >engineering spec. for any technology yet known.
> 
> Actually, my original post may have been somewhat misleading due to "what a 
> global table would look like in say 3 or 5 years after v4 is exhausted" and 
> "in our routers just to take a full table". I wasn't referring to just v6 
> deployment moving forward. I didn't mean after v4 goes away completely. I was 
> adding v4 table + v6 table (assuming we dual-stack, if you separate the two, 
> ~4000 prefixes fit quite nicely on just about anything still running today, 
> and that also makes the second question of my original post irrelevant).  We 
> won't need that amount of memory after v4 goes away (probably for quite some 
> time). The prefix count at that point will be significantly lower. I 
> understand that. Apologies for not being clearer.
> 
Well, once IPv6 is more fully deployed, you'll be seeing at least 30,000 and 
more like 75,000 prefixes in IPv6. That's because there are about 30,000 active 
ASNs today and given tendencies towards traffic engineering, greater 
multihoming, easier address acquisition and some other factors, a 2+ growth 
factor over ASNs wouldn't surprise me in the short term.

> >I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic.
> >I think 6 years is a perfectly reasonable time frame. I think if it takes 11 
> >years
> >it will be because of significant foot-dragging by some key organizations.
> >I'm not convinced that foot-dragging is as likely as some people are, but,
> >there's enough probability to provide some wiggle room in the numbers.
> 
> I agree, although I do think there will be some foot-dragging, I just don't 
> think it will take 11 years. If anyone at that point is still speaking only 
> v4, IMO they'll only be speaking to "127.0.0.1".
> 
I think there will be quite a bit of foot dragging. I think you misunderstand 
me.
I'm expecting everyone to be pretty much dual-stacked in the next 3-4 years,
even with foot dragging. I'm expecting us to start seeing IPv4 actually 
deprecated
as in some providers won't route it any more (or if they do, they'll charge a 
lot
to do so) in 6-11 years. That's what I mean when I say I'd like to see IPv4
go away in that time frame.

Owen

Re: DSL options in NYC for OOB access

[bmanning]

On Wed, Jan 26, 2011 at 08:33:10PM -0500, Warren Kumari wrote:
> 
> On Jan 24, 2011, at 6:22 PM, Nathan Eisenberg wrote:
> 
> >> You can get a CLEAR WiMAX fixed modem with static IP address for $50
> >> (USD) monthly, or less if you opt for the low-bandwidth plan.
> > 
> > I wouldn't dare rely on something of that nature for a lifeline connection. 
> >  I'd spring for the extra $30/mo.  It's expensive, but there ain't nothin' 
> > like a physical cable when it's 3AM on a Sunday.
> > 
> > Nathan

phys plant is good, nesscy but not sufficant for lifeline.

for lifeline - your only option is regulated wireline service
w/o any dependance on external power.  regulated telco voice
service has a requirement for self-power - usually in the range of
12+hours.  Not the 90min batteries in most cell towers.

ymmv of course and you get what you pay for.

--bill

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Fernando Gont]

On 26/01/2011 06:14 a.m., Owen DeLong wrote:
>>> That said.  Any size prefix will likely work and is even permitted by
>>> the RFC.  You do run the risk of encountering applications that assume
>>> a 64-bit prefix length, though.  And you're often crippling the
>>> advantages of IPv6.
>>
>> Just curious: What are the advantages you're referring to?
>>
> 1.Sparse addressing

This comes at a cost, though.


> 2.SLAAC
> 3.RFC 4193 Privacy Addressing

Privacy Extensions "solve" (*) a privacy issue *introduced* by SLAAC
embedding the MAC addresses in the IID. -- So, if anything, I deem this
as a patch, rather than a feature.

(*) there is some bibliography about the effectiveness of privacy
addresses. Some have even argued that they are harmful.


> 4.Never have to worry about "growing" a subnet to hold new machines.

As in #1, this comes at a price.


> 5.Universal subnet size, no surprises, no operator confusion, no bitmath.

With quite a bit of experience with subnetting (from IPv4), I doubt this
can be flagged as a benefit.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Fernando Gont]

On 26/01/2011 11:36 p.m., Douglas Otis wrote:

>>> Discovery implemented at layer 2 fully mitigate these issues?  I too
>>> would be interested in hearing from Radia and Fred.
>> It need not. Also, think about actual deployment of SEND: for instance,
>> last time I checked Windows Vista didn't support it.
> First, it should be noted ND over ARP offers ~16M to 2 reduction in
> traffic.  

Does this really make a difference in a typical LAN?


> Secondly, services offered within a facility can implement
> Secure Neighbor Discovery, since a local network's data link layer, by
> definition, is isolated from the rest of the Internet. 

How many implementations are there of SEND? e.g., Is there SEND support
for Windows?


> While ICMPv6
> supports ND and SeND using standard IPv6 headers, only stateful ICMPv6
> Packets Too Big messages should be permitted.  

Not sure what you mean.



> Nor is Vista, ISATAP, or
> Teredo wise choices for offering Internet services.  At least there are
> Java implementations of Secure Neighbor Discovery.

C'mon. That's great for "proof of concept". But would you raun a real
network with that? Would you deploy e.g., 200+ Windows boxes with
Java-based SEND support? What about all the PKI burden?



> When one considers what is needed to defend a facility's resources,
> Secure Neighbor Discovery seems desirable since it offers hardware
> supported defenses from a wide range of threats.  

Without DNSsec fully deployed, is it worth the effort?


> While it is easy to
> understand a desire to keep specific IP addresses organized into small
> segments, such an approach seems at greater risk and more fragile in the
> face of frequent renumbering.  In other words, it seems best to use IPv6
> secure automation whenever possible.

??



> The make before break feature of IPv6 should also remove most
> impediments related to renumbering.  

One of the most important impediments on renumbering is the IP addresses
hardcoded in configuration files, ACLs, etc. And IPv6 does nothing (and
cannot do anything) to help with that.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Douglas Otis]

On 1/25/11 6:00 PM, Fernando Gont wrote:

On 24/01/2011 08:42 p.m., Douglas Otis wrote:

It seems efforts related to IP address specific policies are likely
doomed by the sheer size of the address space, and to be pedantic, ARP
has been replaced with multicast neighbor discovery which dramatically
reduces the overall traffic involved.

This has nothing to do with the number of entries required in the
Neighbor Cache.

Secondly, doesn't Secure Neighbor
Discovery implemented at layer 2 fully mitigate these issues?  I too
would be interested in hearing from Radia and Fred.

It need not. Also, think about actual deployment of SEND: for instance,
last time I checked Windows Vista didn't support it.
First, it should be noted ND over ARP offers ~16M to 2 reduction in 
traffic.  Secondly, services offered within a facility can implement 
Secure Neighbor Discovery, since a local network's data link layer, by 
definition, is isolated from the rest of the Internet. While ICMPv6 
supports ND and SeND using standard IPv6 headers, only stateful ICMPv6 
Packets Too Big messages should be permitted.  Nor is Vista, ISATAP, or 
Teredo wise choices for offering Internet services.  At least there are 
Java implementations of Secure Neighbor Discovery.


When one considers what is needed to defend a facility's resources, 
Secure Neighbor Discovery seems desirable since it offers hardware 
supported defenses from a wide range of threats.  While it is easy to 
understand a desire to keep specific IP addresses organized into small 
segments, such an approach seems at greater risk and more fragile in the 
face of frequent renumbering.  In other words, it seems best to use IPv6 
secure automation whenever possible.


The make before break feature of IPv6 should also remove most 
impediments related to renumbering.  In other words, fears expressed 
about poorly considered address block assignments also seem misplaced.


-Doug

Re: Upload config to juniper

[Jimmy Hess]

On Mon, Jan 24, 2011 at 7:39 AM, Florin Veres  wrote:
> Hey guys,
> Do any of you have any idea if it's possible to upload configuration from a
> script (prefix-list updates in this case) to a JunOS device (MX)?
> For Cisco devices I'm doing it using rcp.

>From config mode use  a  "load merge"  command that specifies a SCP or FTP  
>URL.
You'll need to setup SSH keys in advance to do so  without an
additional password for the device to download the script.

Alternatively...  SCP the file to a temporary file on the device then
"load merge" the uploaded file,  to merge config from the script.

Net::SSH::Expect from CPAN  to connect  via  ssh  from perl.

Something like
use Net::SSH::Perl;
use Net::SSH::Expect;

my $ssh = Net::SSH::Expect->new(  host =>
'myfavoritehostname.example.com',  user => 'blahblahblah', password =>
'1234',   raw_pty => 1);
$ssh->login(q[blahb...@myfavoritehostname.example.com's password]);
$output1 = $ssh->exec("configure private");
# $blah = $ssh->exec("load merge
usern...@scriptserver.example.com:/path/to/scriptfile_to_load.txt");
print scalar $ssh->exec("show | compare");
# commit

--
-JH

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 3:13 PM, valdis.kletni...@vt.edu wrote:

> On Wed, 26 Jan 2011 12:56:01 -1000, Antonio Querubin said:
>> On Wed, 26 Jan 2011, Owen DeLong wrote:
>> 
 Listen a.b.c.d:80 ->  Listen 80
   ->  
 
>>> That only works if you have only one address on the machine and.
>> 
>> Actually it works fine on machines with multiple IP addresses for both 
>> FreeBSD and CentOS.  And IPv6 enabled servers can easily have multiple 
>> IPv6 addresses.
> 
> What Owen meant was that if you expect it to answer *only* for a.b.c.d:80,
> and *not* to answer for other addresses/interfaces, you may be in for a
> surprise (consider a DMZ host where you have:
> 
> outside world -  128.257.12.2
> inside facing - 192.168.149.149
> 
> VirtualHost 198.168.149.149:80 # super-sekrit corporate internal site
> 
> Changing that VirtualHost to *:80 will probably cause some grief. ;)

Exactly... That is one of MANY examples of the kind of potential
for abuse I was attempting to describe.

Admittedly, if you put your Super-sekrit corporate internal site on a
DMZ host, you arguably deserve what happens, but...

Owen

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 2:59 PM, Antonio Querubin wrote:

> On Wed, 26 Jan 2011, Owen DeLong wrote:
> 
>> It would be nice if BSD would correct their IPV6_V6ONLY behavior instead
>> of putting up an alleged security red herring. I'm not sure why Micr0$0ft 
>> suffers
>> from this braindeath.
> 
> Or at the very least document this in plain site in the IPv6 section of the 
> docs.  Their non-RFC-compliant behaviour is a hidden land mine.
> 
> Antonio Querubin
> e-mail/xmpp:  t...@lava.net

It's actually pretty well known and it is documented in several places in plain
sight.

They're quite proud of their brokenness and they extol the virtues of the
allegedly improved security profile it provides.

I think Rolland Dobbins has coined a good term for it... "Security Theater".
(Though this strikes me as being more like "Security Circus")

Owen

Re: Another v6 question

[Owen DeLong]

On Jan 25, 2011, at 3:35 PM, Max Pierson wrote:

> >I think you may still be missing my point...
> >There are way more /48s available than will ever get used.
> >There are way more /32s available than will ever get used.
> 
> No, I think you're missing my point. Your statements above are of your 
> opinion. The same opinion was said about v4 30 years ago which is why we are 
> where we are today (again, opinions). Reality shows otherwise. 
> 
V4 30 years ago -- expected consumption: ~60 /8s of 256.

IPv6 today -- expected consumption: Maybe 15 /12s of 4096.

The scales in question are vastly different.

> In your opinion, IPv6 is it. We'll NEVER have to do this again. We'll never 
> have to implement NAT (or some other translation protocol) again. We'll never 
> have to worry about running out of space. If thats the case, then why are so 
> many folks arguing over what to give to end users?? It doesn't matter by your 
> opinion. Give em what they want!! There's no possible way we can use that 
> many addresses.
> 
Not at all... In my opinion, IPv6 will probably last about 30-50 years. In my 
opinion, IPv6 addressing will outlast IPv6 usability on other fronts. I 
absolutely think we'll have to do this all again. I just don't think that 
addresses are going to be the thing we run out of next time.

I think people are arguing over what to give end users because people are 
generally bad at large-number arithmetic. The human brain can visualize things 
up to as much as a few hundred. Some people can even visualize a couple of 
thousand. Beyond that, our neurons just think of things as randomly larger 
magnitudes of "a really big number". It all gets lumped into "a whole lot" and 
we lose site of the numeric realities.

> Lets get back to reality. No one, and i'll say it once more, NO ONE knows if 
> v6 is the end all be all. (I would agree with you in regards of our lifetime 
> we won't even use a drop in the bucket). It only took ~10 years to figure out 
> they did it all wrong the first time around. Can you speak for the next 100 
> years, what about 200 years?? (Not that it matters to us anyway, we'll be 
> long gone by then. But they way you put it is that this beast we're dealing 
> with will never have to be revamped again. Future proof! To me, that line of 
> thinking is a little short-sided). 
> 
No, that's not what I said at all. What I said was that addressing isn't going 
to be the constraint that causes us to have to revamp it next time.

Let's put it in perspective... If we give a /48 to every end site, then, we have
enough addresses for 281,474,976,710,656 end sites. There are currently
<7,000,000,000 people on the planet, so, let's assume we give each of them
10 buildings (home, work, a summer cottage, and 7 spares for whatever).
That consumes 70,000,000,000 /48s. Now we're down to 281,404,976,710,656
/48s remaining. If we build 1,000 new end sites every second, we will
need 281,404,976,710 seconds to use them all up. At 86,400 seconds
per day, that's 3,257,002 days or 8,923 years.

I'm pretty sure that we will not be able to sustain building 1,000 new
structures per second for 8,923 years. To do it in 200 years, we
would have to build almost 50,000 new structures every second.

I realize there have been some amazing periods of growth on the
internet, but, even at the peak of the .COM boom, even Cisco wasn't
building at anywhere near that rate.

However, all of this is a bit out of context from what I was saying.
The point was that if you're trying to figure out how big routers are
going to have to be for near-term IPv6 or even medium-term IPv6
deployment, counting the total possible number of prefixes isn't
a useful metric because the actual utilization will be nowhere
near that large and the numbers are impossible to use as an
engineering spec. for any technology yet known.

> 
> Some will care and adapt as we all hope they would, some will simply find 
> another provider with v4 space to spare thats not charging. This won't stop 
> until RIR/LIR's stop re-issuing v4 space. At that point, then the squeeze is 
> on and I would imagine ALL ISP's will charge at that point because they're 
> getting charged for having v4 space.
> 
There will come a time (likely this year) when there isn't another provider 
with v4 space to spare that you can find. One that doesn't charge for it? 
That'll probably happen even earlier.

I think that the RIR/LIRs won't have to stop reissuing space. I think we'll 
rapidly reach a point where space isn't coming back to them to be reissued. At 
least not in meaningful quantities.

> >I don't think IPv4 will continue to grow for all that long. I think the plug 
> >will get pulled by ISPs desperate to reduce the spiraling costs of 
> >continuing to >support IPv4. When it starts becoming increasingly expensive 
> >to get ISPs to provide IPv4 services, the rest of the internet will begin to 
> >move rapidly >away from IPv4.
> 
> >I anticipate this will take about 5-10 yea

Re: DSL options in NYC for OOB access

[Warren Kumari]

On Jan 24, 2011, at 6:22 PM, Nathan Eisenberg wrote:

>> You can get a CLEAR WiMAX fixed modem with static IP address for $50
>> (USD) monthly, or less if you opt for the low-bandwidth plan.
> 
> I wouldn't dare rely on something of that nature for a lifeline connection.  
> I'd spring for the extra $30/mo.  It's expensive, but there ain't nothin' 
> like a physical cable when it's 3AM on a Sunday.
> 
> Nathan
> 
> 

Re: What's the current state of major access networks in North America ipv6 delivery status?

[Rémy Sanchez]

On 01/26/2011 11:02 PM, Owen DeLong wrote:
> Free.fr stuck their customers with /60s, which is
> hopefully a very temporary situation.

Stuck with /64 in practice, which will evolve into /60 when the IPv6
support in their Freebox will be better. I don't think that we'll get
anything more than /60 before the next decade...

At least, they have been able to provide pseudo-native IPv6 for years.
If anyone asks, performances of IPv6 over Free's 6rd are almost the same
than IPv4's.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature

Re: What's the current state of major access networks in North America ipv6 delivery status?

[Mark Andrews]

In message , Owen DeLong write
s:
> 
> On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >=20
> >=20
> > Is anyone tracking the major consumer/business class access networks
> > delivery of ipv6 in North America?
> >=20
> > I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
> > looked into 6rd. Is this a dead end path/giant hack?
> >=20
> > =
> https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Google=
> conf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0
> >=20
> It's a fairly ugly way to deliver IPv6, but, as transition technologies
> go, it's the least dead-end of the options.
> 
> It at least provides essentially native dual stack environment. The
> only difference is that your IPv6 access is via a tunnel. You'll =
> probably
> be limited to a /56 or less over 6rd, unfortunately, but, because of the
> awful way 6rd consumes addresses, handing out /48s would be
> utterly impractical. Free.fr stuck their customers with /60s, which is
> hopefully a very temporary situation.

This comes from using a single 6rd prefix for all the clients.

Those saying this is the way to do this really havn't thought about
what they are going to have to do once they can't get enough IPv4
addresses to give a public one to each customer that needs a IPv4
addresses and also needs 6rd.  The "simple" solution of a signgle
prefix doesn't work.

6rd doesn't have to consume space badly and it shouldn't consume
space badly if done right.

DHCP servers don't hand out the same router to each client.  They
hand out the same router to all clients on the same subnet.  ISP's
are capable of configuring their DHCP servers to do that.  Configuring
them to hand out a 6rd prefix on a per subnet basis is no harder.

Just ask for a /48 for each IPv4 address you intend to support 6rd
on.  For each block IPv4 block you get from RIR you specify a
matching 6rd prefix.  This prefix is stable for the life of the
IPv4 block's allocation.  When you get a new IPv4 block you add the
6rd prefix to the configuration system.

If you are using RFC 1918 addresses to connect to your customers
and NATing that you request enough /48's to cover the amout of RFC
1918 space you are using.

If you are re-using space in multiple places then 6rd becomes a
little more complicated as the prefixes need to differ for each
re-uses.  Note the naive single 6rd prefix doesn't work in this
situation so ISPs doing this will need do something more complicated.

Also give that address space will almost certainly need to be re-used
while 6rd is also in use I fail to see the objection to doing it
sensibly from the get go.

Down the track I can see 6rd prefixes being allocated on request
being just one more thing that the consumer can request via a web
form.  This will allow the ISP to recover the space being used by
6rd.

> >=20
> > I spoke with impulse.net last year, which appears to serve large
> > portions of the AT&T cable plant in Southern California. They were
> > willing to offer native ipv6. Not sure how (one /64, a /48) etc.
> >=20
> You should definitely push your providers to give you a /48 if
> possible. If /56 or worse /60 or worst of all, /64 become widespread
> trends, it may significantly impact, delay, or even prevent innovations
> in the end-user networking/consumer electronics markets.
> 
> Owen
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Karl Auer]

On Wed, 2011-01-26 at 11:53 +0700, Roland Dobbins wrote:
> On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote:
> The supreme irony of this situation is that folks who're convinced
> that there's no way we can even run out of addresses often accuse
> those of us who're plentitude-skeptics of old-fashioned thinking;
> whereas there's a strong case to be made that those very same vocal
> advocates of the plentitude position seem to be assuming that the
> assignment and consumption of IPv6 addresses (and networking
> technology and the Internet in general) will continue to be
> constrained by the current four-decade-old paradigm into the
> foreseeable future.

Both positions are wrong, but the plenitudinists are more right :-)

As long as we allow ourselves to be limited in our thinking by numbers
(which are infinite by their very nature), we will be - well, limited in
our thinking.

So let's get rid of the limitation in our minds. IPv6 provides
*effectively* unlimited address space, even if it's only "for now". So
let's USE it that way. Let's unlearn our limited thinking patterns.
Let's go colonise infinity. And if we need to fix it in a few decades,
so what? Nothing is forever.

As Mark Twain suggested, let's "live like it's heaven on earth".

Regards, K.

PS: I saw a great t-shirt recently, ideal for your next IPv6 conference:
"The time for action is past
- now is the time for senseless bickering".

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

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156


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

Re: What's the current state of major access networks in North America ipv6 delivery status?

[Owen DeLong]

On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> Is anyone tracking the major consumer/business class access networks
> delivery of ipv6 in North America?
> 
> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
> looked into 6rd. Is this a dead end path/giant hack?
> 
> https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
> 
It's a fairly ugly way to deliver IPv6, but, as transition technologies
go, it's the least dead-end of the options.

It at least provides essentially native dual stack environment. The
only difference is that your IPv6 access is via a tunnel. You'll probably
be limited to a /56 or less over 6rd, unfortunately, but, because of the
awful way 6rd consumes addresses, handing out /48s would be
utterly impractical. Free.fr stuck their customers with /60s, which is
hopefully a very temporary situation.

> 
> I spoke with impulse.net last year, which appears to serve large
> portions of the AT&T cable plant in Southern California. They were
> willing to offer native ipv6. Not sure how (one /64, a /48) etc.
> 
You should definitely push your providers to give you a /48 if
possible. If /56 or worse /60 or worst of all, /64 become widespread
trends, it may significantly impact, delay, or even prevent innovations
in the end-user networking/consumer electronics markets.

Owen

Re: Ipv6 for the content provider

[Mark Andrews]

Additionally for DNS don't forget to add IPv6 glue for the nameservers
for your zones to the parent zones.

For named in particular listen-on-v6 needs to be specified as it
is not on by default e.g. "listen-on-v6 { any; };".  Named will ask
questions over IPv6 by default even if it isn't listening on IPv6.

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

Re: Upload config to juniper

[John Adams]

I do this with pyexpect for blacklist updating. It works amazingly well.

One thing to remember when communicating with the JunOS device is that
if you fail to disable the CLI controls, communicating with the device
is very difficult.

I do something like:

  import pexpect
  child = pexpect.spawn ('ssh',
['-p','22','-o','StrictHostKeyChecking=no',"router ip address goes
here"], 2)

  child.sendline("set cli screen-length 0")
  child.sendline("set cli screen-width 0")

  < put your commands here to talk to the router >

-j


On Mon, Jan 24, 2011 at 5:39 AM, Florin Veres  wrote:
> Hey guys,
>
> Do any of you have any idea if it's possible to upload configuration from a
> script (prefix-list updates in this case) to a JunOS device (MX)?
> For Cisco devices I'm doing it using rcp.
>
> Thanks,
> Florin
>

Upload config to juniper

[Florin Veres]

Hey guys,

Do any of you have any idea if it's possible to upload configuration from a
script (prefix-list updates in this case) to a JunOS device (MX)?
For Cisco devices I'm doing it using rcp.

Thanks,
Florin

Re: Ipv6 for the content provider

[Valdis . Kletnieks]

On Wed, 26 Jan 2011 12:56:01 -1000, Antonio Querubin said:
> On Wed, 26 Jan 2011, Owen DeLong wrote:
> 
> >>  Listen a.b.c.d:80 ->  Listen 80
> >>->  
> >>
> > That only works if you have only one address on the machine and.
> 
> Actually it works fine on machines with multiple IP addresses for both 
> FreeBSD and CentOS.  And IPv6 enabled servers can easily have multiple 
> IPv6 addresses.

What Owen meant was that if you expect it to answer *only* for a.b.c.d:80,
and *not* to answer for other addresses/interfaces, you may be in for a
surprise (consider a DMZ host where you have:

outside world -  128.257.12.2
inside facing - 192.168.149.149

VirtualHost 198.168.149.149:80 # super-sekrit corporate internal site

Changing that VirtualHost to *:80 will probably cause some grief. ;)


pgpMgguXmEeJv.pgp
Description: PGP signature

Re: What's the current state of major access networks in North America ipv6 delivery status?

[Antonio Querubin]

On Wed, 26 Jan 2011, Charles N Wyble wrote:


How about TimeWarnerCable? They don't seem to have any sort of v6
offering, on wholesale or retail services.


TW Cable has no IPv6 offering.

However, TW Telecom provides IPv6 connectivity upon request.  By default 
they only provide a /56 if you need multiple subnets and you have to 
provide further justification to get a /48.



Antonio Querubin
e-mail/xmpp:  t...@lava.net

Re: Ipv6 for the content provider

[Antonio Querubin]

On Wed, 26 Jan 2011, Randy McAnally wrote:


The only issue I've faced is RHEL/CentOS doesn't have stateful connection
tracking for IPv6 - so ip6tables is practically worthless.


As long as you're willing to run your iptables through a modification 
filter to generate the corresponding ip6tables you should be ok.  The 
following sed script might come in handy.


s/-p icmp --icmp-type any/-p icmpv6/
/-m state --state ESTABLISHED,RELATED/ {
  s/-m state --state ESTABLISHED,RELATED/-p udp -m udp --dport 32768:61000/p
  s/udp/tcp/g
  s/61000/61000 ! --syn/
}
s/-m state --state NEW //
s/224.0.0.251/ff02::fb/
s/icmp-host-prohibited/icmp6-adm-prohibited/

Modify as needed.  YMMV.


Antonio Querubin
e-mail/xmpp:  t...@lava.net

Re: Ipv6 for the content provider

[Antonio Querubin]

On Wed, 26 Jan 2011, Owen DeLong wrote:


It would be nice if BSD would correct their IPV6_V6ONLY behavior instead
of putting up an alleged security red herring. I'm not sure why Micr0$0ft 
suffers
from this braindeath.


Or at the very least document this in plain site in the IPv6 section of 
the docs.  Their non-RFC-compliant behaviour is a hidden land mine.


Antonio Querubin
e-mail/xmpp:  t...@lava.net

Re: Ipv6 for the content provider

[Lamar Owen]

On Wednesday, January 26, 2011 05:01:31 pm Randy McAnally wrote:
> I've worked around it by compiling custom (newer) Kernels on systems that need
> it.  Apparently support was added some time around 2.6.20, but of course RHEL5
> is still in the dark ages of 2.6.18.

RHEL has the eMRG kernel available that is post-2.6.18, for RHEL5.

However, RHEL's 2.6.18 kernel has many many things backported from much more 
recent kernels, including features like ext4.  Saying that it's an old kernel 
isn't completely true; it's kind of like saying a '67 C2 Vette with a 327 has 
an old engine (after all, why not the 427?), but what you don't see is the 
sixty-thousandths overbore, 18 degree BowTie heads, forged crank,  a 1300CFM 
Holley Dominator 4500 on an Edelbrock Victor Glidden single-plane port-matched 
18 degree intake, along with Flowmaster long tube headers, long lobe COMP cam, 
and high stall torque converter that makes it more than just an old 327... 
Sorry, dream car there and, yes, I'd rather have the tricked-out 327 small 
block than the 427 big-blockalthough that carb on that intake isn't the 
most street-friendly combination ever imagined 

Don't judge a kernel by the superficial version number; look for the 
performance parts under the hood, and maybe even under the valve covers

Re: Ipv6 for the content provider

[Antonio Querubin]

On Wed, 26 Jan 2011, Owen DeLong wrote:


 Listen a.b.c.d:80 ->  Listen 80
   ->  


That only works if you have only one address on the machine and.


Actually it works fine on machines with multiple IP addresses for both 
FreeBSD and CentOS.  And IPv6 enabled servers can easily have multiple 
IPv6 addresses.



If you have addresses that aren't intended for name-based-site-A but
do terminate SSL connections to sites B, C, and D, then you probably
don't want to use * for site A.


Generally, I've found this doesn't really matter too much since the view 
from the outside world to the server will be funneled via DNS records. 
Site A can still be referenced by a * in the Apache config since the A and 
 records will probably reference only the name-based IP addresses for 
the server while sites B, C, and D DNS records reference site-specific 
addresses also residing on the same server.  The bottom line is that the 
Apache config can be kept simple and free of hard-coded addresses except 
where absolutely necessary.



Use hard-coded IP addresses only where required for stuff like SSL-enabled 
webhosts.


Depends on the complexity of your environment. In a more complex configuration
you can actually save yourself a lot of trouble and confusion later by using a
construct like this:

Listen 192.159.10.7:80
Listen [2620:0:930::dead:beef:cafe]:80
Listen [2620:0:930::400:7]:80

ServerName www.delong.com


I'd do that only for the SSL-enabled sites.  Otherwise the generic 
name-based Apache config should work fine for just about everything else.


Antonio Querubin
e-mail/xmpp:  t...@lava.net

Re: What's the current state of major access networks in North America ipv6 delivery status?

[Charles N Wyble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1




On 01/26/2011 01:52 PM, Charles N Wyble wrote:
> 
> Is anyone tracking the major consumer/business class access networks
> delivery of ipv6 in North America?
> 
> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
> looked into 6rd. Is this a dead end path/giant hack?
> 
> https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
> 

Found an article talking about at&t v6 support

http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3

Also found
http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNQKEzAAoJEMvvG/TyLEAt45cP/0g+8lNUb1z6Ew/tWgGPEYWu
u7wemSTjs27yxKXIbdfWzcWizvX3THHFNW6oRlRIdaH3z+Ttkzb/ne5wEDw9lcgV
vnW0n/QjKQOWFaZ+chgEpplEVPth5jww/B/o9taeS7MXonbhQipTeTo3/U7am0GB
MCZXngLllOhPZmmjhqsssiLX94wjc5uvqSdAExTt7aXQ7+SaVzpFghXTZgWAG9eE
X9JpFeLhJMNPed1MOzxOn7WTsqDu2sHyszoyrZwGyjyQ/JZFDFfdhE3qQPRe97tv
ZOmlfPYFjJRjQ4MlY7iX+BI/CTRAeM+59oslpX8h7VeGY4zmlNGw8dhR1yvB400h
w+/GubudSnL50XppUslKWbl03v+4dTQYMy3dotwH2OM8ovcJMn596rLW8j+3zV7t
zcOuLSLFlqY6QZYy8tp705qzYesLWvHJJlpbXryyOGoz/5SJyTvfkDywOgyNeXz4
siU2a+JaAxlJsrBc9YsabCY8C60zFQxKBwANXWhvP7TZiFtt+SaNLp/Eahh9NoAO
Zygs4FekumT9TFeNsAnPlHFFCl9v6fU0Yxc8u0ffYa2+hW6f/2My4tY0n07PNd8l
DUUO7h9GtLpfEgTk2eLavY8HZcb1RtA4cvMe8n1J2GOVCwpGfOD0xl1Y3AX6v+rk
JuGqPIfyQ8GiNtj7KzRV
=LASk
-END PGP SIGNATURE-

Re: What's the current state of major access networks in North America ipv6 delivery status?

[TJ]

On Wed, Jan 26, 2011 at 16:52, Charles N Wyble wrote:

(SNIP)

Comcast is currently conducting trials:
> http://comcast6.net/ (anyone participated in this?)
>

Yes, I am in one of their trials now.
For the trial I am in (Residential cable, 6RD) they shipped me a
Cisco/Linksys running OpenWRT/LuCI.
Mostly been working great ...



/TJ

Re: Ipv6 for the content provider

[Valdis . Kletnieks]

On Wed, 26 Jan 2011 13:56:05 PST, Charles N Wyble said:

> > The only issue I've faced is RHEL/CentOS doesn't have stateful connection
> > tracking for IPv6 - so ip6tables is practically worthless.
> 
> 
> H. Interesting. I wonder if this is specific to the RedHat kernel?
> Or a problem with v6 support on Linux in general?

(Linux kernels are trying to stick to a release-every-3-months schedule).

RHEL/CentOS 5 is using a 2.6.18 kernel.  The needed support for stateful IPv6
landed in 2.6.21 or so (so almost a year after RHEL 5 did its feature freeze).
RHEL 6 is apparently a 2.6.32 kernel so it should be there. Cutting edge kernel
is currently 2.6.38-rc2.




pgpCl64f1Yxu2.pgp
Description: PGP signature

Re: Ipv6 for the content provider

[Randy McAnally]

On Wed, 26 Jan 2011 13:56:05 -0800, Charles N Wyble wrote

> > The only issue I've faced is RHEL/CentOS doesn't have stateful connection
> > tracking for IPv6 - so ip6tables is practically worthless.
> 
> H. Interesting. I wonder if this is specific to the RedHat 
> kernel?

I've worked around it by compiling custom (newer) Kernels on systems that need
it.  Apparently support was added some time around 2.6.20, but of course RHEL5
is still in the dark ages of 2.6.18.

~Randy

Re: Ipv6 for the content provider

[Charles N Wyble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/26/2011 01:50 PM, Randy McAnally wrote:
> On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote
> 
>> For the most part, I'm a data center/application 
>> administrator/content provider kind of guy. As such, I want to 
>> provide all my web content over ipv6, and support ipv6 SMTP.  What 
>> are folks doing in this regard?
> 
> The only issue I've faced is RHEL/CentOS doesn't have stateful connection
> tracking for IPv6 - so ip6tables is practically worthless.


H. Interesting. I wonder if this is specific to the RedHat kernel?
Or a problem with v6 support on Linux in general? Perhaps it could be
solved with tweaking which iptables modules get loaded. Ugh. This is why
I don't care for iptables as a firewall. Lost lots of time tracking down
bizarre corner cases due to module issues. Don't get me started on the
number of issues due to distro patching of the kernel.

I haven't used Linux for any serious networking duty for some time. Just
Cisco and pfsense. However the majority of my servers are Linux (Ubuntu
10.10/8.04) (with a couple of windows 2008 servers).




- -- 
Charles N Wyble (char...@knownelement.com)
Systems craftsman for the stars
http://www.knownelement.com
Mobile: 626 539 4344
Office: 310 929 8793
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNQJh0AAoJEMvvG/TyLEAt5pQP/iSi5x43vW5oGGsatcMXCFnz
nd4vXZrMlujHazd9DAYwkbwHUXkdXq26sQk+k3Ah90rBecpRJPm6y0O5Gyoktdex
oxEP1CRLsgWk1kJFa2aSqS/Lh3loJgXHRaY17sNiqbqWoNXz9meh8oLNATFM5iu0
2uFgxJKQhEGv0iwWUFXtzXkUlQxdFNP71+AcCKY6mhaLYdVUUasmFWrwsumN0KNo
WsVhTqI8LLow0HcfOjhxI7QD2m84Hl46oUyIzZ05I2g4iI0BD6UyvrGW2FKEsuml
9Fwb9kULuNBO9vJRPu0PyzgFL6qYtjTC3EigUP8/wpsSDC6TxLLXuZI5cSZnnd8M
DOpjhL2854eTNq2IKicaxwb5U+Hq6E4rbpKFZxutvo9z3nFKGOwQx8qUnMiFgNu9
i4oASTus3ZLOkMncacXFxI8CJlvOGlktAeWdDfJ+z1ebCutgtCC1Qkgz7EFGq2oe
zejLgMZsKVkr3Ezmiij7CTlrHCiWFeNrl9OLkGs7uB8Kx7SJmJlWRxsU3mfm72np
4Q1MQrk8NSI687S/XI3yf/q0+E73eI7ldYdivstubN5VcPpQDMFOQ/7yYm7AeM7V
IbnPwkICxTQqJNALTB3QUFBq5UM26MRONFhi58TAOSkkwgQzyuLarLI4eBft43sx
NQ6IrlMG0nFYl1h12SGy
=gbrP
-END PGP SIGNATURE-

Re: Ipv6 for the content provider

[Dale W. Carder]

Thus spake Randy McAnally (r...@fast-serv.com) on Wed, Jan 26, 2011 at 
04:50:22PM -0500:
> On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote
> 
> > For the most part, I'm a data center/application 
> > administrator/content provider kind of guy. As such, I want to 
> > provide all my web content over ipv6, and support ipv6 SMTP.  What 
> > are folks doing in this regard?
> 
> The only issue I've faced is RHEL/CentOS doesn't have stateful connection
> tracking for IPv6 - so ip6tables is practically worthless.

Yep, we ran into this too early on with rhel [4,5].  Have you looked at rhel 6?

Dale

What's the current state of major access networks in North America ipv6 delivery status?

[Charles N Wyble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Is anyone tracking the major consumer/business class access networks
delivery of ipv6 in North America?

I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
looked into 6rd. Is this a dead end path/giant hack?

https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0


I spoke with impulse.net last year, which appears to serve large
portions of the AT&T cable plant in Southern California. They were
willing to offer native ipv6. Not sure how (one /64, a /48) etc.

I see that FiOS did a trial in April 2010
http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-testing-ipv6.html
(it mentions special CPE). What about verizon DSL?

Comcast is currently conducting trials:
http://comcast6.net/ (anyone participated in this?)

How about TimeWarnerCable? They don't seem to have any sort of v6
offering, on wholesale or retail services.


Am I missing anyone in the DSL/Cable/FTTH market?

As for wireless broadband providers, there is satellite and 3g/4g/LTE. I
haven't looked at the satellite providers. I know Verizon is offering
dual stack on their LTE service, according to a thread a couple weeks
ago.  T-mobile is offering it on the small subset of phones that have v6
capable baseband.

For grins and giggles, how does North America stack up against other
regions, when it comes to access network ipv6 delivery.

Thanks.

- -- 
Charles N Wyble (char...@knownelement.com)
Systems craftsman for the stars
http://www.knownelement.com
Mobile: 626 539 4344
Office: 310 929 8793
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNQJd/AAoJEMvvG/TyLEAtIx4P/1ehNtwotF30HZf4BqeWlJ7C
gGmp33VkvwPdh8qUT4scHT/Wcql2V/ijhEJk7t0Tu9F98ig51c3euLuJ9iUhgP8v
RdX9Ty8uAThs2EL/sT3aEVlrbiEOtkjW5zFQzWv3So7aPFeO9u5uBa9XO2eeOFG4
nI1ztpPzq3obGGLZWixIJ3ukOvKnb1ilKk74h9kjvnRA89wE1nS8ZvulWdWovAZ6
CaiU54SARQFlqtZ5PsrPrAi1LEz5lXP3Pp3kvphjp019XmyPvtgFwqwX6WoMbBgQ
hHulUEnTX9A/3S/Llzz/eQRcWDX+KtqfF/khNBglsr6Y8tBgvJ360YI7dmn9J2hS
1QmnkiwTKlSkvbBM9HVbC/no7nB/J4ybOTVV004ciY6WWTRnCNGtgnoUWO4+qJVK
E0996B2egOmhkUJs8AR+VYsguEVbSc12wbxZYrfjTjh7yE87q92okw/mUVi5OOVL
t+ysZpV6yifR6/0T26VTJnJ/Ha6tjOE8SmA6lSKdKac5GTPkFBRqzkqsgGmF3lQq
NAYMaVKmmq58j5e3eA8btGNf/u4wzJv9JJFXx3aij7pCE29yAfSrMfNV8r6ayAvL
lDXQH3AP6LpV6EPb2vAUPq95iw+Fvl5PN80PYdyxVwpphQRutYQYvPZBh9/RfFOi
LL5HLupKb900MQX/ZMjY
=tE8q
-END PGP SIGNATURE-

Re: Ipv6 for the content provider

[Randy McAnally]

On Wed, 26 Jan 2011 10:22:40 -0800, Charles N Wyble wrote

> For the most part, I'm a data center/application 
> administrator/content provider kind of guy. As such, I want to 
> provide all my web content over ipv6, and support ipv6 SMTP.  What 
> are folks doing in this regard?

The only issue I've faced is RHEL/CentOS doesn't have stateful connection
tracking for IPv6 - so ip6tables is practically worthless.

~Randy

RE: Ipv6 for the content provider

[George Bonser]

> That's definitely a bug. Mapped addresses should never hit the wire.
> 
> Dual stack is quite a bit safer than NAT64/DNS64. The bug you describe
> should be fairly trivial to get fixed if someone can isolate which
> product
> actually has the bug. Have you tried the current kernel under the
> existing
> other components? If swapping the kernel doesn't fix it (I think the
> mapped address on the wire bugs in the Linux kernel were removed
> fairly early in the 2.6 chain IIRC), then it's probably Java.
> 
> Owen

It was a fairly recent kernel (2.6.31-19  #56 Ubuntu) and uptime on the
machine I was testing on is a bit less than a year so it hasn't been
updated in a while.  I will try it again once that machine gets updated.
I have seen a few bugs in various Ubuntu kernel builds, too.  Such as in
one build ND is broken (machine responds to its own DAD probes so it
thinks any address it tries to use is in use) but the previous build and
subsequent build (all of the same kernel version, just different patch
tinkering by Ubuntu) work ok.


 

Multiple WAN setup for Bridge customers on Ericsson SmartEdge Platform

[Tony Esparza]

Hello,

I was wondering if anyone has successfully deployed a multi WAN product using 
encapsulation bridge1483 on the Ericsson SmartEdge platform.

Please hit me offline, I can forward you my configs.

Tony

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 11:18 AM, George Bonser wrote:

>> 
>> Application level support on Linux/FreeBSD/NetBSD is 98% and rising
>> every day.  Apache, BIND, Postfix, they all work great.  The "problem"
>> is you may need config adjustment.  Your Apache ListenOn's will need
>> IPv6 added, your Postfix "local nets" ACL will need your IPv6
> addresses
>> added, and so on.
>> 
>> And that is the crux of the migration issue.  Updating all the
>> configuration in all the apps to both do the right thing and be secure
>> in IPv6.  That is where all of your work will be, particualrly if you
>> have custom systems to manage IP's or configs.
>> 
>> --
>>   Leo Bicknell - bickn...@ufp.org - CCIE 3440
>>PGP keys at http://www.ufp.org/~bicknell/
> 
> We're still having some problems with linux and java.  For example, a v6
> socket is supposed to support either protocol. But for some reason, and
> I don't know if this is just one particular kernel, if communications is
> attempted under some circumstances with a v4 address on a dual-stacked
> host, the packets go out on the wire with v6 mapped v4 addresses
> (:::x.x.x.x) which isn't supposed to happen.  So everything isn't
> quite there yet for dual-stacking all applications.  The "safest"
> approach on paper is v6 native using NAT64/DNS64 but getting the NAT64
> piece in place at production quality and scale is a problem at this
> point.
> 
> 

That's definitely a bug. Mapped addresses should never hit the wire.

Dual stack is quite a bit safer than NAT64/DNS64. The bug you describe
should be fairly trivial to get fixed if someone can isolate which product
actually has the bug. Have you tried the current kernel under the existing
other components? If swapping the kernel doesn't fix it (I think the
mapped address on the wire bugs in the Linux kernel were removed
fairly early in the 2.6 chain IIRC), then it's probably Java.

Owen

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 11:17 AM, Francois Tigeot wrote:

> On Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote:
>> For the most part, I'm a data center/application administrator/content
>> provider kind of guy. As such, I want to provide all my web content over
>> ipv6, and support ipv6 SMTP.  What are folks doing in this regard?
>> 
>> Do I just need to assign ip addresses to my servers, add  records to
>> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
>> WWW. Postfix for SMTP.
> 
> Depending on your local configuration, you may have to change some minor
> options (e.g add a IPv6 Listen line for Apache), but yeah, in general it's
> as simple as adding an  record in the DNS.
> 
> The only troublesome applications I still encounter these days are
> Munin (monitoring stuff: http://www.munin-monitoring.org/) and anything
> that's Java based.
> 
> If its running on a IPv6-enabled host, Java wants to use IPv6 sockets for
> everything - including IPv4 connections.

If you're not on a broken BSD or Windows implementation, that shouldn't be a 
problem.

It would be nice if BSD would correct their IPV6_V6ONLY behavior instead
of putting up an alleged security red herring. I'm not sure why Micr0$0ft 
suffers
from this braindeath.

> Most modern operating systems do not allow this; you have to force the use
> of either IPv4 or IPv6 and disable the other protocol.
> 
Not true. Other than BSD/Windows, most modern operating systems actually
follow the RFCs in this regard. Even most of the BSD derivatives will allow
you to correctly set IPV6_V6ONLY=False to correct the errant default
behavior.

Owen

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 11:17 AM, Antonio Querubin wrote:

> On Wed, 26 Jan 2011, Charles N Wyble wrote:
> 
>> Do I just need to assign ip addresses to my servers, add  records to
>> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
>> WWW. Postfix for SMTP.
> 
> Best to remove IP version dependencies in your configs.
> 
> If you are using name-based virtual hosting in Apache, convert:
> 
>  Listen a.b.c.d:80 ->  Listen 80
>->  
> 
That only works if you have only one address on the machine and.

If you have addresses that aren't intended for name-based-site-A but
do terminate SSL connections to sites B, C, and D, then you probably
don't want to use * for site A.

> Use hard-coded IP addresses only where required for stuff like SSL-enabled 
> webhosts.
> 
Depends on the complexity of your environment. In a more complex configuration
you can actually save yourself a lot of trouble and confusion later by using a
construct like this:

Listen 192.159.10.7:80
Listen [2620:0:930::dead:beef:cafe]:80
Listen [2620:0:930::400:7]:80

ServerName www.delong.com
...


YMMV, but, that's working reliably in my environment for:

[root@owen conf]# host www.delong.com
www.delong.com has address 192.159.10.7
www.delong.com has IPv6 address 2620:0:930::400:7

(The dead:beef:cafe address isn't currently in the s that are publicly 
visible because
it's used for testing specialized testing from different DNS views.)

The machine in question has a number of IPv4 and IPv6 addresses many
of which terminate HTTP/HTTPs connections, some of which do not.

Owen

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 11:22 AM, George Bonser wrote:

>> And if your servers behind the LB aren't prepared for it, you lose a
>> LOT
>> of logging data, geolocation capabilities, and some other things if
> you
>> go that route.
>> 
>> Owen
> 
> Relying on IP address for geolocation is actually quite ridiculous
> though I do realize that many people seem to believe that you can map an
> IP address to the physical location of the originator of the data, at
> least to the country level, but I suppose some people will sell you
> anything.
> 
> We haven't seen any problem with logging data so far in our testing.
> 

I don't disagree, but, since people like Wells Fargo are using it as a
security check (ask me about my experiences trying to log in from
Rwanda to check on a mortgage payment some time), things that
potentially make it even more broken than it is are worth pointing
out to administrators that may be stuck implementing IPv6 on sites
that may have such dependencies.

Owen

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 11:10 AM, David Freedman wrote:

>>> 
>>> 
>> And if your servers behind the LB aren't prepared for it, you lose a LOT
>> of logging data, geolocation capabilities, and some other things if you
>> go that route.
>> 
>> Owen
>> 
>> 
>> 
> 
> I can't imagine an LB vendor who would sell a v6 to v4 vip solution who
> wouldn't provide a way to inject the v6 addr in to the request as an
> additional header? I suggest a naming-and-shaming is in order
> 
Sure, but, if you're not prepared to parse, log, and deal with that header,
then, you lose, right?

Note I said "IF your servers behind the LB aren't prepared for it..."

Owen

Re: IPv6 filtering

[Michael Loftis]

On Tue, Jan 25, 2011 at 10:49 PM, Mark D. Nagel  wrote:

> This can bite you in unexpected ways, too.  For example, on a Cisco ASA,
> if you add a system-level 'icmpv6 permit' line and if this does not
> include ND, then you break ND responses to the ASA.  This is much unlike
> ARP, which is unaffected by 'icmp permit' statements for IPv4.  And, the
> default with no such lines is to permit all ICMP/ICMPv6 to the ASA. This
> seems so obvious in retrospect, but at the time was a bit of a
> head-scratcher.
>

ARP is a seperate protocol supporting IPv4 ... For IPv6 ND is done
using ICMPv6 messages.  A bit confusing transitioning from IPv4/ARP
for sure.

> Mark

Re: Ipv6 for the content provider

[Dale W. Carder]

Thus spake Leo Bicknell (bickn...@ufp.org) on Wed, Jan 26, 2011 at 10:55:26AM 
-0800:
> 
> The layer 3 part for you is really simple.  Here's a deployment model we
> use a number of places.  I'm going to assume you have a /48, from ARIN
> or your upstream.
> 
> Lay out your networks as:
>   :::::/64
> 
> The ::::/48 was given to you by ARIN/your upstream.
> For VLAN I recommend being human friendly and making vlan 10 be
> :::0010::/64, even though that's technically 16 in Hex.

At our site, we very strongly discourage mapping like this.  Your addressing
plan will outlive your infrastructure, and you will be stuck with it until 
renumbering is no longer hard.

Dale

Re: Ipv6 for the content provider

[Dale W. Carder]

Thus spake Jack Carrozzo (j...@crepinc.com) on Wed, Jan 26, 2011 at 01:38:48PM 
-0500:
> As I understand it, when a client requests a particular domain of yours and 
> gets
> an A and an , the client will default to the  (assuming it's on a v6
> network) and attempt to communicate as such. Failing that, it will fall back
> to the v4 A record.

This is true for now.  

See http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6
for a proposal on how this could change.

Dale

Re: Ipv6 for the content provider

[Antonio Querubin]

On Wed, 26 Jan 2011, Antonio Querubin wrote:


Best to remove IP version dependencies in your configs.

If you are using name-based virtual hosting in Apache, convert:

 Listen a.b.c.d:80 ->  Listen 80
   ->  

Use hard-coded IP addresses only where required for stuff like SSL-enabled 
webhosts.


In postfix just add to main.cf:

 inet_interfaces = all
 inet_protocols = all

And make sure your MX hostnames have  RRs.


One additional note.  Add your IPv6 prefixes to mynetworks.  The IPv6 
prefix should be enclosed in brackets before the prefix length.  Ie. the 
IPv6 loopback would be added as [::1]/128.



Antonio Querubin
e-mail/xmpp:  t...@lava.net

RE: Ipv6 for the content provider

[George Bonser]

> And if your servers behind the LB aren't prepared for it, you lose a
> LOT
> of logging data, geolocation capabilities, and some other things if
you
> go that route.
> 
> Owen

Relying on IP address for geolocation is actually quite ridiculous
though I do realize that many people seem to believe that you can map an
IP address to the physical location of the originator of the data, at
least to the country level, but I suppose some people will sell you
anything.

We haven't seen any problem with logging data so far in our testing.

RE: Ipv6 for the content provider

[George Bonser]

> 
> Application level support on Linux/FreeBSD/NetBSD is 98% and rising
> every day.  Apache, BIND, Postfix, they all work great.  The "problem"
> is you may need config adjustment.  Your Apache ListenOn's will need
> IPv6 added, your Postfix "local nets" ACL will need your IPv6
addresses
> added, and so on.
> 
> And that is the crux of the migration issue.  Updating all the
> configuration in all the apps to both do the right thing and be secure
> in IPv6.  That is where all of your work will be, particualrly if you
> have custom systems to manage IP's or configs.
> 
> --
>Leo Bicknell - bickn...@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/

We're still having some problems with linux and java.  For example, a v6
socket is supposed to support either protocol. But for some reason, and
I don't know if this is just one particular kernel, if communications is
attempted under some circumstances with a v4 address on a dual-stacked
host, the packets go out on the wire with v6 mapped v4 addresses
(:::x.x.x.x) which isn't supposed to happen.  So everything isn't
quite there yet for dual-stacking all applications.  The "safest"
approach on paper is v6 native using NAT64/DNS64 but getting the NAT64
piece in place at production quality and scale is a problem at this
point.

Re: Ipv6 for the content provider

[Francois Tigeot]

On Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble wrote:
> For the most part, I'm a data center/application administrator/content
> provider kind of guy. As such, I want to provide all my web content over
> ipv6, and support ipv6 SMTP.  What are folks doing in this regard?
> 
> Do I just need to assign ip addresses to my servers, add  records to
> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
> WWW. Postfix for SMTP.

Depending on your local configuration, you may have to change some minor
options (e.g add a IPv6 Listen line for Apache), but yeah, in general it's
as simple as adding an  record in the DNS.

The only troublesome applications I still encounter these days are
Munin (monitoring stuff: http://www.munin-monitoring.org/) and anything
that's Java based.

If its running on a IPv6-enabled host, Java wants to use IPv6 sockets for
everything - including IPv4 connections.
Most modern operating systems do not allow this; you have to force the use
of either IPv4 or IPv6 and disable the other protocol.

I had to put these options in a Tomcat startup script:
  -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true

-- 
Francois Tigeot

Re: Ipv6 for the content provider

[Antonio Querubin]

On Wed, 26 Jan 2011, Charles N Wyble wrote:


Do I just need to assign ip addresses to my servers, add  records to
my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
WWW. Postfix for SMTP.


Best to remove IP version dependencies in your configs.

If you are using name-based virtual hosting in Apache, convert:

  Listen a.b.c.d:80 ->  Listen 80
->  

Use hard-coded IP addresses only where required for stuff like SSL-enabled 
webhosts.


In postfix just add to main.cf:

  inet_interfaces = all
  inet_protocols = all

And make sure your MX hostnames have  RRs.


Antonio Querubin
e-mail/xmpp:  t...@lava.net

Re: Ipv6 for the content provider

[Loránd Jakab]

On 01/26/2011 07:46 PM, Owen DeLong wrote:
>> Do I just need to assign ip addresses to my servers, add  records to
>> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
>> WWW. Postfix for SMTP.
>>
> It might be that simple, it might not. Depends on your application.
>
> For the DNS and Mail, it should be pretty much that simple. I don't know
> about the state of Postfix (don't use it), but, sendmail has been IPv6
> ready for years and I'm running with it no problem.

I run a low traffic mail server with Postfix, and setting up IPv6 was as
easy as adding  records for the MX-es and enabling 'inet_protocols =
all' in main.cf

-Lorand Jakab

Re: Ipv6 for the content provider

[David Freedman]

>>
>>
> And if your servers behind the LB aren't prepared for it, you lose a LOT
> of logging data, geolocation capabilities, and some other things if you
> go that route.
>
> Owen
>
>
>

I can't imagine an LB vendor who would sell a v6 to v4 vip solution who
wouldn't provide a way to inject the v6 addr in to the request as an
additional header? I suggest a naming-and-shaming is in order


-- 


David Freedman
Group Network Engineering
Claranet Group

Re: Ipv6 for the content provider

[Leo Bicknell]

In a message written on Wed, Jan 26, 2011 at 10:22:40AM -0800, Charles N Wyble 
wrote:
> For the most part, I'm a data center/application administrator/content
> provider kind of guy. As such, I want to provide all my web content over
> ipv6, and support ipv6 SMTP.  What are folks doing in this regard?
> 
> Do I just need to assign ip addresses to my servers, add  records to
> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
> WWW. Postfix for SMTP.

The layer 3 part for you is really simple.  Here's a deployment model we
use a number of places.  I'm going to assume you have a /48, from ARIN
or your upstream.

Lay out your networks as:

  :::::/64

The ::::/48 was given to you by ARIN/your upstream.
For VLAN I recommend being human friendly and making vlan 10 be
:::0010::/64, even though that's technically 16 in Hex.

The vlan's consume 4096 of your 65536 subnets, so you still have
many more to play with.  Want to know what address to configure,
well, you can guess if you know the vlan number.

We then also do the same thing with the address, if it's a static
server.  Say the server was 10.2.50.210.  We re-use the 210 part,
and get :::0010::210, assuming it is on VLAN 10.

So you assign addresses to your boxes, decide if you want static
default routes or want to allow them to learn a default via RA, and
well, you're basically done for Layer 3.

Application level support on Linux/FreeBSD/NetBSD is 98% and rising
every day.  Apache, BIND, Postfix, they all work great.  The "problem"
is you may need config adjustment.  Your Apache ListenOn's will
need IPv6 added, your Postfix "local nets" ACL will need your IPv6
addresses added, and so on.

And that is the crux of the migration issue.  Updating all the
configuration in all the apps to both do the right thing and be
secure in IPv6.  That is where all of your work will be, particualrly
if you have custom systems to manage IP's or configs.

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


pgpnbbE3DNjjJ.pgp
Description: PGP signature

Re: Ipv6 for the content provider

[Graham Beneke]

On 26/01/2011 20:22, Charles N Wyble wrote:

For the most part, I'm a data center/application administrator/content
provider kind of guy. As such, I want to provide all my web content over
ipv6, and support ipv6 SMTP.  What are folks doing in this regard?

Do I just need to assign ip addresses to my servers, add  records to
my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
WWW. Postfix for SMTP.


I haven't worked with Postfix recently but Exim on a default config will 
start talking IPv6 as soon as it has connectivity. Just be careful of 
this since you need to make sure that all your rDNS, SPF, etc ducks are 
in a row before you give it IPv6 since it can start delivering mail via 
IPv6 with very little encouragement.


With Apache I've had some funnies with how it binds (or fails) to IPv4 
and IPv6 sockets at startup. Once you're over that hurdle I've found 
that the majority of open source web apps either support IPv6 or are 
designed correctly to not be impacted by other layers in the network stack.


Its important to keep a close eye on logs and also don't roll out to all 
your servers in one go. The gradual migration to dual stack has been 
fairly painless for me.


--
Graham Beneke

Re: Ipv6 for the content provider

[Owen DeLong]

On Jan 26, 2011, at 10:39 AM, George Bonser wrote:

> 
> 
>> From: Charles N Wyble 
>> Sent: Wednesday, January 26, 2011 10:23 AM
>> To: nanog@nanog.org
>> Subject: Ipv6 for the content provider
>> 
>> For the most part, I'm a data center/application administrator/content
>> provider kind of guy. As such, I want to provide all my web content
>> over
>> ipv6, and support ipv6 SMTP.  What are folks doing in this regard?
>> 
>> Do I just need to assign ip addresses to my servers, add  records
>> to
>> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
>> WWW. Postfix for SMTP.
>> 
>> Feel free to point me at any good manuals and say RTFM :)
> 
> 
> Most load balancers these days will allow you to provision an IPv6
> virtual IP that balances to v4 servers.  So you can provide services
> over v6 without a lot of changes inside your network.  You will need a
> DNS server that hands out  records though.
> 
> 
And if your servers behind the LB aren't prepared for it, you lose a LOT
of logging data, geolocation capabilities, and some other things if you
go that route.

Owen

Re: Ipv6 for the content provider

[Owen DeLong]

> 
> Do I just need to assign ip addresses to my servers, add  records to
> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
> WWW. Postfix for SMTP.
> 
It might be that simple, it might not. Depends on your application.

For the DNS and Mail, it should be pretty much that simple. I don't know
about the state of Postfix (don't use it), but, sendmail has been IPv6
ready for years and I'm running with it no problem.

As to the web, Apache is fully IPv6 ready and that's easy. It will
take IPv6 addresses in all the same places you would configure
IPv4 addresses. You do need to enclose the address portion
in brackets with the port number outside the brackets.

e.g.: 2620:0:930::400:7 on port 80 = [2620:0:930::400:7]:80

Other considerations that may be important:

1.  Load balancers
2.  Log parsers
3.  UI stuff that accepts or reports IP addresses
Application
Site Administration
CMS
4.  Databases that contain IP address(es)
5.  Other tools, files, etc. that may interact with IP addresses

All of those things will need additional attention as you add IPv6
capabilities to your site. Some sites have to worry about all 5.
Some sites don't have to worry about any of these things.

I was able to do all the web sites I host at home just by adding
the appropriate Apache configs and putting in the 
records next to the A records. Took me about an hour for a
couple dozen sites.

I've received exactly zero user complaints since the IPv6
implementation.

More complex environments may take considerably more effort.

Owen

RE: Ipv6 for the content provider

[George Bonser]

> From: Charles N Wyble 
> Sent: Wednesday, January 26, 2011 10:23 AM
> To: nanog@nanog.org
> Subject: Ipv6 for the content provider
> 
> For the most part, I'm a data center/application administrator/content
> provider kind of guy. As such, I want to provide all my web content
> over
> ipv6, and support ipv6 SMTP.  What are folks doing in this regard?
> 
> Do I just need to assign ip addresses to my servers, add  records
> to
> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
> WWW. Postfix for SMTP.
> 
> Feel free to point me at any good manuals and say RTFM :)


Most load balancers these days will allow you to provision an IPv6
virtual IP that balances to v4 servers.  So you can provide services
over v6 without a lot of changes inside your network.  You will need a
DNS server that hands out  records though.

Re: Ipv6 for the content provider

[Jack Carrozzo]

Bind and apache work with v6 out of the box, and have for years. As I
understand it, when a client requests a particular domain of yours and gets
an A and an , the client will default to the  (assuming it's on a v6
network) and attempt to communicate as such. Failing that, it will fall back
to the v4 A record.

So in short, yes, it's as simple as telling the daemons to listen on your v6
addresses and adding the  records. Just think how happy your 1
client/customer using IPv6 will be ;-)

-Jack Carrozzo

On Wed, Jan 26, 2011 at 1:22 PM, Charles N Wyble
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
>
> All the recurring threads about prefix length, security posture, ddos,
> consumer CPE support have been somewhat interesting to my service
> provider alter ego. Ipv6 is definitely on folks minds this year. The
> threads seem a lot less trollish as well. It appears some significant
> progress is being made, and peoples opinions are firming up. Hopefully
> this will help move ipv6 adoption forward.
>
> I have recently turned up an ipv6 tunnel with he.net and have end to end
> connectivity. I'm using pfsense as my routing platform. It was pretty
> easy (about 10 minutes of total work I think). So I can connect to
> various ipv6 enabled sites on the interwebz. This seems to be the first
> step in deployment.
>
>
> For the most part, I'm a data center/application administrator/content
> provider kind of guy. As such, I want to provide all my web content over
> ipv6, and support ipv6 SMTP.  What are folks doing in this regard?
>
> Do I just need to assign ip addresses to my servers, add  records to
> my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
> WWW. Postfix for SMTP.
>
> Feel free to point me at any good manuals and say RTFM :)
>
>
>
> - --
> Charles N Wyble (char...@knownelement.com)
> Systems craftsman for the stars
> http://www.knownelement.com
> Mobile: 626 539 4344
> Office: 310 929 8793
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJNQGZvAAoJEMvvG/TyLEAt9ykP/ROLSWz3LmAF78OMBEhWEMvX
> MjOVR2QK6kQ3byV8WLro95tCOuyo8L8fUC60KyFh4XRsedb7xk6S8cTER80zmGzG
> rOAFVpNyJ1QzCcf4MYpj8xHn9zM6Fywft4VzKQEgDvlV8yD0VZKJi+fNj4noZ5oK
> tmM1s9Is5db3d5ldrC6M54TQJsbaZiuz+FrFtpkENraJIWlOeU3laM6kvwzvYpok
> BKtnaY6zBq42QovpJ+MU+lmanCB6Z0r3e2cSB+N7XJL0Va/Y2IW/eZn35S+dE3xk
> y7RPSZu2jDxJ6atQJVIBpjfL6oqUUr+0RHc+gX4VJyOrwpEuJQ/GvTiRDTUZkA0A
> twhvQnS6yc5G8L+iwID4YqkVKNCFcJUtAHUntqmy1FqTe9iQSlZdUPPhKrkRE7zW
> B2S2T0Lv6a/neHU5yfsGjiYbIAy7keXoiMPbR4ZJxC/KkogfWNgMZBVpjGVn0NI4
> COOymyFYgvQFiXIpvmpQn0iLFcWmmGdwV2DPvxMArdmfw2SeyipJiBSeeEbb4ZG4
> kw1LOrI7+OGnoDEByAtkZPh42wAbXbrSw9WeWvphAsQ2dAmASqXUKuHTDXd1laCC
> yi37NTRmWACNHKcVEhpk3saJDCsPPVx6ECYfhSsSALZDn6696BvFXZnN2423Fmk7
> dtMKM38+rxz9r4IL5O+n
> =Mi6R
> -END PGP SIGNATURE-
>
>

Ipv6 for the content provider

[Charles N Wyble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,


All the recurring threads about prefix length, security posture, ddos,
consumer CPE support have been somewhat interesting to my service
provider alter ego. Ipv6 is definitely on folks minds this year. The
threads seem a lot less trollish as well. It appears some significant
progress is being made, and peoples opinions are firming up. Hopefully
this will help move ipv6 adoption forward.

I have recently turned up an ipv6 tunnel with he.net and have end to end
connectivity. I'm using pfsense as my routing platform. It was pretty
easy (about 10 minutes of total work I think). So I can connect to
various ipv6 enabled sites on the interwebz. This seems to be the first
step in deployment.


For the most part, I'm a data center/application administrator/content
provider kind of guy. As such, I want to provide all my web content over
ipv6, and support ipv6 SMTP.  What are folks doing in this regard?

Do I just need to assign ip addresses to my servers, add  records to
my DNS server and that's it? I'm running PowerDNS for DNS, Apache for
WWW. Postfix for SMTP.

Feel free to point me at any good manuals and say RTFM :)



- -- 
Charles N Wyble (char...@knownelement.com)
Systems craftsman for the stars
http://www.knownelement.com
Mobile: 626 539 4344
Office: 310 929 8793
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNQGZvAAoJEMvvG/TyLEAt9ykP/ROLSWz3LmAF78OMBEhWEMvX
MjOVR2QK6kQ3byV8WLro95tCOuyo8L8fUC60KyFh4XRsedb7xk6S8cTER80zmGzG
rOAFVpNyJ1QzCcf4MYpj8xHn9zM6Fywft4VzKQEgDvlV8yD0VZKJi+fNj4noZ5oK
tmM1s9Is5db3d5ldrC6M54TQJsbaZiuz+FrFtpkENraJIWlOeU3laM6kvwzvYpok
BKtnaY6zBq42QovpJ+MU+lmanCB6Z0r3e2cSB+N7XJL0Va/Y2IW/eZn35S+dE3xk
y7RPSZu2jDxJ6atQJVIBpjfL6oqUUr+0RHc+gX4VJyOrwpEuJQ/GvTiRDTUZkA0A
twhvQnS6yc5G8L+iwID4YqkVKNCFcJUtAHUntqmy1FqTe9iQSlZdUPPhKrkRE7zW
B2S2T0Lv6a/neHU5yfsGjiYbIAy7keXoiMPbR4ZJxC/KkogfWNgMZBVpjGVn0NI4
COOymyFYgvQFiXIpvmpQn0iLFcWmmGdwV2DPvxMArdmfw2SeyipJiBSeeEbb4ZG4
kw1LOrI7+OGnoDEByAtkZPh42wAbXbrSw9WeWvphAsQ2dAmASqXUKuHTDXd1laCC
yi37NTRmWACNHKcVEhpk3saJDCsPPVx6ECYfhSsSALZDn6696BvFXZnN2423Fmk7
dtMKM38+rxz9r4IL5O+n
=Mi6R
-END PGP SIGNATURE-

Re: PPPOE vs DHCP

[Jack Bates]

On 1/26/2011 11:03 AM, Tim Franklin wrote:

So they're telling us, at least for PPPoE specifically.  Cisco solution is "buy 
ASR".



This is same solution they've given for the 7206 and other traditional 
IOS platforms. I haven't checked, but all the RBE/unnumbered vlan 
support for IPv6 with proxy-ND, better radius backend for DHCPv6, and 
supposedly IA_TA support for DHCPv6 will be in the ASR only. The 
features in IOS SR train are somewhat functional but extremely limited.


If I find myself having to spend money on ASRs, I may just spend the 
money replacing them with Juniper. Only reason I haven't is that I 
haven't needed to spend the money at all.


Jack

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Jack Bates]

I believe it has to do with IPv6 mechanisms for handling native 
addressing. I haven't had the opportunity to test it myself, but from 
dealing with other vendors, I find that they all support subsets of 
possible configurations. For example, we test the following with each 
CPE device which supports IPv6 and is up for consideration.


1) 6to4 support
2) SLAAC + DHCPv6-PD on bridging wan (haven't found one yet, and I 
believe still the only setup for IOS)
3) DHCPv6 IA_TA requests + DHCPv6-PD (too bad IOS SR doesn't support 
this yet?)
4) Support of RA to determine default route (seen many require manual 
gateway configurations since DHCPv6 won't send a default router option)

5) PPPoE/A with above combinations
6) PPPoE/A unnumbered ptp + DHCPv6-PD
7) /60 and /48 DHCPv6-PD and how they are assigned by the CPE
8) DHCPv6 IA_TA, SLAAC, and DHCPv6-PD support on the device's LAN and 
determining the mechanism it uses

9) Default stateful firewall rules for IPv6.
10) Support for static assignments and routing for IPv6 (many devices 
are still working on dynamic support and have no manual support)


I've yet to find a consumer grade product which meets all of these 
different configurations; especially in the $50 range.



Jack

On 1/26/2011 11:01 AM, Owen DeLong wrote:

I haven't done exhaustive testing, but, it has to do with certain combinations
of IPv4 configurations and IPv6 routing do work and other combinations
don't.

Owen

On Jan 26, 2011, at 4:41 AM, Richard Barnes wrote:


Could you elaborate?  Which circumstances?

On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong  wrote:

It works for routing native IPv6 under some circumstances as well.

Owen

On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote:





On Wed, 26 Jan 2011, Franck Martin wrote:


What about an Airport Extreme? It has a wan interface that does PPPOE

The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 
firewall.


Yes it is. I already reported to Marco.
http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey

It should be included somehow in a matrix But 6to4 (or other tunneling 
techniques) is only a substitute of real IPv6.

Regards,
   Janos Mohacsi



- Original Message -
From: "Mirjam Kuehne"
To: nanog@nanog.org
Sent: Tuesday, 25 January, 2011 3:34:14 AM
Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[apologies for duplicates]

Hello,

Based on new information we received since the last publication, we
updated the IPv6 CPE matrix:

http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011

In order to make this information more useful for a large user base, we
are preparing a detailed survey to gather more structural feedback about
the range of equipment that is currently in use. Not only would we like
you to participate in this survey, but we also ask for your help in
identifying the right survey questions. Please find a call for input on
RIPE Labs:

http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed

Kind Regards,
Mirjam Kuehne&  Marco Hogewoning
RIPE NCC

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Owen DeLong]

On Jan 25, 2011, at 2:07 PM, valdis.kletni...@vt.edu wrote:

> On Tue, 25 Jan 2011 16:17:59 EST, Ricky Beam said:
>> On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong  wrote:
>>> Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s.
>> 
>> Those who don't learn from history are doomed to repeat it.
>> 
>> "Dude, there are 256 /8 in IPv4."
>> 
>> "640k ought to be enough for anyone."
>> 
>> People can mismange anything into oblivion.  IPv6 will end up the same  
>> mess IPv4 has become. (granted, it should take more than 30 years this  
>> time.)
> 
> To burn through all the /48s in 100 years, we'll have to use them up
> at the rate of 89,255 *per second*.
> 
> That implies either *really* good aggregation, or your routers having enough
> CPU to handle the BGP churn caused by 90K new prefixes arriving on the 
> Internet
> per second.  Oh, and hot-pluggable memory, you'll need another terabyte of RAM
> every few hours.  At that point, running out of prefixes is the *least* of 
> your
> worries.
> 
This presumes that we don't run out of /48s by installing them in routers a /20 
at a time.

Owen

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Owen DeLong]

I haven't done exhaustive testing, but, it has to do with certain combinations
of IPv4 configurations and IPv6 routing do work and other combinations
don't.

Owen

On Jan 26, 2011, at 4:41 AM, Richard Barnes wrote:

> Could you elaborate?  Which circumstances?
> 
> On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong  wrote:
>> It works for routing native IPv6 under some circumstances as well.
>> 
>> Owen
>> 
>> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote:
>> 
>>> 
>>> 
>>> 
>>> On Wed, 26 Jan 2011, Franck Martin wrote:
>>> 
 What about an Airport Extreme? It has a wan interface that does PPPOE
 
 The IPv6 feature seems working, with 6to4 or static tunnels and a basic 
 IPv6 firewall.
>>> 
>>> Yes it is. I already reported to Marco.
>>> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey
>>> 
>>> It should be included somehow in a matrix But 6to4 (or other tunneling 
>>> techniques) is only a substitute of real IPv6.
>>> 
>>> Regards,
>>>   Janos Mohacsi
>>> 
 
 - Original Message -
 From: "Mirjam Kuehne" 
 To: nanog@nanog.org
 Sent: Tuesday, 25 January, 2011 3:34:14 AM
 Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
 
 [apologies for duplicates]
 
 Hello,
 
 Based on new information we received since the last publication, we
 updated the IPv6 CPE matrix:
 
 http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
 
 In order to make this information more useful for a large user base, we
 are preparing a detailed survey to gather more structural feedback about
 the range of equipment that is currently in use. Not only would we like
 you to participate in this survey, but we also ask for your help in
 identifying the right survey questions. Please find a call for input on
 RIPE Labs:
 
 http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed
 
 Kind Regards,
 Mirjam Kuehne & Marco Hogewoning
 RIPE NCC
 
 
 
>> 
>> 
>> 

Re: PPPOE vs DHCP

[Tim Franklin]

> 10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in 
> utilizing the IOS SR line. I've played with PPPoE and bridging on the
> 7200s mostly. I need to kick up an ASR, as I hear it's specialized
> code line has much better IPv6 support than IOS SR. both XR/XE codes
> seem to be much more richly featured, especially for radius backending
> DHCP.

So they're telling us, at least for PPPoE specifically.  Cisco solution is "buy 
ASR".

Regards,
Tim.

Re: PPPOE vs DHCP

[Jack Bates]

On 1/26/2011 9:36 AM, Tim Franklin wrote:

Terminating PPPoE generally isn't much different than terminating
VLANs.  In Juniper world, it requires the right equipment. Cisco
world, it's not generally a big deal.


Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and 
now want IPv6 on your PPPoE.  Not that I'm becomming increasingly bitter about 
that platform or anything...



10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in 
utilizing the IOS SR line. I've played with PPPoE and bridging on the 
7200s mostly. I need to kick up an ASR, as I hear it's specialized code 
line has much better IPv6 support than IOS SR. both XR/XE codes seem to 
be much more richly featured, especially for radius backending DHCP.



Jack

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Ray Soucy]

I think we're losing focus on the discussion here.

The core issue here is that ND tables have a finite size, just like
ARP tables.  Making an unsolicited request to a subnet will cause ND
on the router to try and reach find the host.

This can be a problem with subnets as small as 1024 (I constantly find
people using Linux-based routers, for example, running with the kernel
default ARP table of 127 instead of bumping it up to a sane and
network appropriate level).

I don't believe that using smaller IPv6 prefixes is an appropriate
response to the problem.  In time, we will likely see protection
mechanisms come from vendors.  Perhaps disabling the ability for
routers to solicit ND and just depend on connected hosts to announce
their presence would be sufficient.  Perhaps not.  It is something
that needs to be looked into, just like DAD DoS attacks, and rogue RA
on the LAN.  But it has little to do with prefix length.

When it comes down to it.  I find it hard to justify attempting to
mitigate this DoS vector by using longer prefixes.  There are many
many more useful and effective DoS vectors that are lower-hanging
fruit.  And the lowest hanging fruit always wins.

On Tue, Jan 25, 2011 at 1:42 PM, Owen DeLong  wrote:
>
> On Jan 25, 2011, at 8:58 AM, Patrick Sumby wrote:
>
>> On 24/01/2011 22:41, Michael Loftis wrote:
>>> On Mon, Jan 24, 2011 at 1:53 PM, Ray Soucy  wrote:
>>>
 Many cite concerns of potential DoS attacks by doing sweeps of IPv6
 networks.  I don't think this will be a common or wide-spread problem.
  The general feeling is that there is simply too much address space
 for it to be done in any reasonable amount of time, and there is
 almost nothing to be gained from it.
>>>
>>> The problem I see is the opening of a new, simple, DoS/DDoS scenario.
>>> By repetitively sweeping a targets /64 you can cause EVERYTHING in
>>> that /64 to stop working by overflowing the ND/ND cache, depending on
>>> the specific ND cache implementation and how big it is/etc.  Routers
>>> can also act as amplifiers too, DDoSing every host within a multicast
>>> ND directed solicitation group (and THAT is even assuming a correctly
>>> functioning switch thats limiting the multicast travel)
>
> I love this term... "repetitively sweeping a targets /64".
>
> Seriously? Repetitively sweeping a /64? Let's do the math...
>
> 2^64 = 18,446,744,073,709,551,616 IP addresses.
>
> Let's assume that few networks would not be DOS'd by a 1,000 PPS
> storm coming in so that's a reasonable cap on our scan rate.
>
> That means sweeping a /64 takes 18,446,744,073,709,551 sec.
> (rounded down).
>
> There are 86,400 seconds per day.
>
> 18,446,744,073,709,551 / 86,400 = 213,503,982,334 days.
>
> Rounding a year down to 365 days, that's 584,942,417
> years to sweep the /64 once.
>
> If we increase our scan rate to 1,000,000 packets
> per second, it still takes us 584,942 years to sweep
> a /64.
>
> I don't know about you, but I do not expect to live long
> enough to sweep a /64, let alone do so repetitively.
>
> Owen
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities

Advisory ID: cisco-sa-20110126-csg2

http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml

Revision 1.0

For Public Release 2011 January 26 1600 UTC (GMT)

+-

Summary
===

A service policy bypass vulnerability exists in the Cisco Content
Services Gateway - Second Generation (CSG2), which runs on the
Cisco Service and Application Module for IP (SAMI). Under certain
configurations this vulnerability could allow:

  * Customers to access sites that would normally match a billing
policy to be accessed without being charged to the end customer
  * Customers to access sites that would normally be denied based on
configured restriction policies

Additionally, Cisco IOS Software Release 12.4(24)MD1 on the Cisco
CSG2 contains two vulnerabilities that can be exploited by a remote,
unauthenticated attacker to create a denial of service condition that
prevents traffic from passing through the CSG2. These vulnerabilities
require only a single content service to be active on the Cisco CSG2 and
can be exploited via crafted TCP packets. A three-way handshake is not
required to exploit either of these vulnerabilities.

Workarounds that mitigate these vulnerabilities are not available.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml.

Affected Products
=

The service policy bypass vulnerability affects all versions of the
Cisco IOS Software for the CSG2 prior to the first fixed release, as
indicated in the "Software Versions and Fixes" section of this advisory.

The two denial of service vulnerabilities only affect Cisco IOS Software
Release 12.4(24)MD1 on the Cisco CSG2. No other Cisco IOS Software
releases are affected.

Vulnerable Products
+--

To determine the version of Cisco IOS Software that is running on the
Cisco CSG2, issue the "show module" command from Cisco IOS Software on
the switch on which the Cisco CSG2 module is installed to identify what
modules and sub-modules are installed on the system.

Cisco CSG2 runs on the Cisco Service and Application Module for IP
(SAMI) card, and is identified in the following example in slot 2 via
the WS-SVC-SAMI-BB-K9 identification:

C7600#show module
Mod Ports Card Type  Model  Serial 
No.
--- - -- -- 
---
  12  Supervisor Engine 720 (Active) WS-SUP720-3BXL 
JAF1226ARQS
  21  SAMI Module (csgk9)WS-SVC-SAMI-BB-K9  
SAD113906P1
  4   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX 
SAL1127T6XY

Mod MAC addresses   HwFw   Sw   
Status
--- -- --   
---
  1  001e.be6e.a018 to 001e.be6e.a01b   5.6   8.5(2)   12.2(33)SRC5 Ok
  2  001d.45f8.f3dc to 001d.45f8.f3e3   2.1   8.7(0.22)FW1 12.4(2010040 Ok
  4  001c.587a.ef20 to 001c.587a.ef4f   2.6   12.2(14r)S5  12.2(33)SRC5 Ok

Mod  Sub-Module  Model  Serial   Hw 
Status
 --- -- --- --- 
---
  1  Policy Feature Card 3   WS-F6K-PFC3BXL JAF1226BNQM  1.8Ok
  1  MSFC3 Daughterboard WS-SUP720  JAF1226BNMC  3.1Ok
  2  SAMI Daughterboard 1SAMI-DC-BB SAD114400L9  1.1
Other
  2  SAMI Daughterboard 2SAMI-DC-BB SAD114207FU  1.1
Other
  4  Centralized Forwarding Card WS-F6700-CFC   SAL1029VGFK  2.0Ok

Mod  Online Diag Status
 ---
  1  Pass
  2  Pass
  4  Pass
C7600#

After locating the correct slot, issue the "session slot 
processor <3-9>" command to open a console connection to the respective
Cisco CSG2. Once connected to the Cisco CSG2, perform the "show version"
command:

The following example shows that the Cisco CSG2 is running software
Release 12.4(24)MD1:

CSG2#show version
Cisco IOS Software, SAMI Software (SAMI-CSGK9-M), Version 12.4(24)MD1, 
RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Wed 07-Apr-10 09:50 by prod_rel_team


--- output truncated ---

Products Confirmed Not Vulnerable
+

The Cisco Content Services Gateway - 1st Generation (CSG) is not
affected by these vulnerabilities.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
===

The Cisco Content Services Gateway - Second Generation (CSG2) provides
intelligent network capabilities such as flexible poli

Re: PPPOE vs DHCP

[Tim Franklin]

> Terminating PPPoE generally isn't much different than terminating
> VLANs.  In Juniper world, it requires the right equipment. Cisco
> world, it's not generally a big deal.

Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and 
now want IPv6 on your PPPoE.  Not that I'm becomming increasingly bitter about 
that platform or anything...

Regards,
Tim.

Re: Network Naming

[Bill Blackford]

What I found when visiting this in my own organization that being an
Enterprise and "pseudo" service provider, is that naming fits into
several categories.

1. Hostnames/Prompts
2. Rack Switches in Data centers
3. Path. Meaning routed  interfaces that the world sees in the form of
PTR records.

Prompts:

{Organization}-{Site}-{Dist_Frame}-{Device_Type}{Number}

MYCORP-HQ-2B-S1  (My_Corp., headquarters, 2nd Fl idfb, switch1.

Another way I've named prompts is with relative DNS suffix. This tends
to work best with routers, not so much for rack or access gear.
ex,

CAR1.INAP.STTL#

full DNS name: car1.inap.sttl.my-corp.net


Racks:

Same as above just replacing frame with rack#


Path:
{Interface_Type}{number}.{Device_Type}{number}.{Geo_Location}.{org_fqdn}

For interface type I've been sticking to the Juniper convention as I
find it more consistent than that of Ciscos.

I have a document that describes the convention of every field of
every type in order to maintain consistency.

What I struggle with is trying to find a consistent naming convention
for gear behind the firewall vs. on the outside that is publicly
visible.

-b



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.

Re: Network Naming

[Cutler James R]

> I recommend documenting your naming standard and getting buy in across your 
> organization before you put it into place. 

This is a necessary condition for successful deployment, but not part of the 
schema.



On Jan 25, 2011, at 11:32 PM, David Miller wrote:

> On 1/25/2011 8:15 PM, Gary Steers wrote:
>> James makes a good point...
>> 
>>> Pick a scheme which:
>>>  1. Uses simple memorable names.
>>>  2. Makes business sense to you.
>>>  3. You know how to manage (database, publication, updates, etc.
>>> If I had to weight these criteria, I would weight 3 most heavily.
>> 
>> The other key thing to bear in mind is consistency and scalability... (i.e. 
>> design a scope that can grow with your network and needs
>> 
>> {interface/server}.{router/vmhost}.{city}.{country}.example.net
>> 
>> The other thing that doesn't really have any defined list is {city}, Some 
>> people prefer 2 letter, some 3 letter, some people use airport codes etc..
>> 
> 
> The naming schemes that I have developed that needed to be upgraded in the 
> past have almost always bumped up against scale, so build in much larger 
> scale than you ever think that you will need from the beginning.  You have X 
> devices now in Y locations, but your naming scheme should scale to X^Z 
> devices in Y^Z locations.
> 
> I agree that for network gear, this is is a good place to start (slightly 
> simplified here from above):
> 
> {interface}.{host}.{location}.example.net
> 
> 
> - Location
>  I personally prefer UN LOCODEs for country / city.  The UN already went to 
> the trouble of giving a unique code to every country/city.  Why do I use 
> them?  LON makes perfect sense as London, England... until you have devices 
> in London, KY and London, OH (the LOCODES for these Londons are GB LON, US 
> LDN, US LOZ).  In my opinion, airport codes (while certainly unique) work 
> well in some locales and not so well in others (so, I don't use them, YMMV).
> 
> - Host
>  I prefer, like many do, an acronym denoting the primary function of the 
> device.  ES (edge switch), AR (access router), CR (core router), etc... 
> whatever your internal terminology is.  If you will *ever* have more than 10 
> of a device anywhere, then I would recommend that you number out of double 
> digits (more than 100, then out of triple digits...).  That way in a sorted 
> list AR03 will be right between AR02 and AR04, where you expect it to be, 
> instead of between AR29 and AR30.  Standardizing on number length also limits 
> ambiguity in pressure situations and/or over noisy or less reliable 
> communication channels.
> 
> - Interface
>  Port names vary on gear from different vendors.  {interface type} - 
> {selector}* ... where selector repeats ordered from highest to lowest level 
> of granularity (e.g. rack/slot/module/port) is what I use.  You should use 
> whatever makes sense to you.  Are interface speeds or vlans important to your 
> infrastructure?  If so, then include them where appropriate.  Unless you have 
> exactly the same gear everywhere, you are going to have to be flexible here.
> 
> I recommend documenting your naming standard and getting buy in across your 
> organization before you put it into place.  By giving names to these 
> devices/interfaces at all, you are exposing information to the world.  What 
> makes perfect sense to engineering and support may give security, management, 
> and/or marketing heart palpitations.
> 
> Just my $0.02 (probably overvalued).
> 
>> Hope that helps!
>> 
>> G
>> 
>> ---
>> Gary Steers
>> Sharedband NOC/3rd Line Support
>> Sharedband
>> UK: +44 (0)1473 287207
>> US: +1 206 420 0240
>> E: gary.ste...@sharedband.com
>> 
>> We have a new support system - http://support.sharedband.com
>> 
>> 
>> -Original Message-
>> From: Cutler James R [mailto:james.cut...@consultant.com]
>> Sent: 25 January 2011 22:41
>> To: nanog group
>> Subject: Re: Network Naming
>> 
>> On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote:
>> 
>>> Whats the rule of thumb for naming gear these days
>>> (routers,switches...etc). Or is there one?
>> Pick a scheme which:
>> 1. Uses simple memorable names.
>> 2. Makes business sense to you.
>> 3. You know how to manage (database, publication, updates, etc.
>> 
>> If I had to weight these criteria, I would weight 3 most heavily.
>> 
>> 
>> James R. Cutler
>> james.cut...@consultant.com
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

James R. Cutler
james.cut...@consultant.com

Re: PPPOE vs DHCP

[isabel dias]

http://www.cisco.com/en/US/products/hw/routers/ps295/products_configuration_example09186a0080093e3b.shtml


http://s-tools1.juniper.net/solutions/literature/white_papers/200187.pdf


3rd party vendors might want to have me onboard :-) otherwise you can come up 
w/ 
your own piece of kit, rfc' it and a few white papers bla and boom, start your 
own business like the others have done in the past ..

 




From: Paul Stewart 
To: Miquel van Smoorenburg 
Cc: nanog@nanog.org
Sent: Wed, January 26, 2011 1:40:49 PM
Subject: RE: PPPOE vs DHCP

Thank you for the response...

I should have made this a bit clearer - option 82 is an option on their
DSLAM's today and is supposed to work "not bad".  But this customer may also
be looking at other services such as wireless in the future which does not
support option 82 - they want a unified delivery of their product.  I left
out this detail as you can see ;)

Also, the comment " so a customer doesn't have to configure his/her router
to get online" is also interesting - we WANT our customers to configure
their routers and understand them to a basic degree... this coming from a
security perspective where we are seeing a magnitude to customer routers
getting hacked or their wireless left open etc.

Usage based billing is a very hot topic in this area (Ontario, Canada) and
we will confirm with the customer today that they do indeed want to track
all GB usage per customer... 

Today, they have no interest nor can they get IPv6 which is a shame
having said that, we want to provide a solution to them than can do IPv6 in
the future...

Thanks,

Paul


-Original Message-
From: Miquel van Smoorenburg [mailto:mik...@xs4all.net] 
Sent: Wednesday, January 26, 2011 4:16 AM
To: p...@paulstewart.org
Cc: nanog@nanog.org
Subject: Re: PPPOE vs DHCP

In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
>PPPOE vs DHCP
>Allows full authentication of customers (requires username/password)

You probably want to authenticate on circuit id, not username/password.
ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added
by the DSLAM or FTTH access switch when using an ethernet transport layer.
It's just a different radius attribute to authenticate on, no magic.
We do that so a customer doesn't have to configure his/her router
to get online.

>Easily assign static IP to customer (no MAC address or CPE information
>required)

Don't need that with DHCP either, if you run a DHCP server that can
assign IP addresses based on option82. I run a patched ISC dhcp3 server,
but I understand that ISC dhcp4 makes this pretty easy

>Assign public subnet to customer with ease (no manual routing required)

Don't need manual routing with DHCP either, if you use a real
bras such as a juniper, since you can have it authenticate off
radius first before doing DHCP, and in the radius reply you can
return a static route.

>Usage tracking (GB transfer) from radius generated data

True, at least juniper e-series BRASes don't send radius accounting
for atm rfc1483/bridged connections for some reason.

>DHCP Cons
>
>-

One more DHCP con is that if you have an ethernet transport network
from the DSLAM or FTTH access switch to your router that lumps together 
multiple customers in one VLAN, something along the way is probably
doing DHCP sniffing to set up routing. And you can be just about sure
that won't work with IPv6. VLAN-per-customer will work (and is a
really a great model, for all types of encapsulation)

Mike.

Re: PPPOE vs DHCP

[Jack Bates]

On 1/26/2011 8:12 AM, Paul Stewart wrote:

No, we're not putting ERX's at people's homes ... not sure where you got
that from?   What I was saying is that if you're running PPPOE then you have
have somewhere in the service provider network to "terminate" the
sessions

Hey. It was the middle of the night. I completely misread which side of 
the termination you were referring to.


Terminating PPPoE generally isn't much different than terminating VLANs. 
In Juniper world, it requires the right equipment. Cisco world, it's not 
generally a big deal.



Jack

RE: PPPOE vs DHCP

[Paul Stewart]

> PPPOE Cons
>
> --
>
>
>
> Requires PPPOE termination router (Juniper ERX for example)
>
You're putting Juniper ERXs at customer houses? Really? I'd expect to 
see DSL/Cable drops which will utilize cheap end CPE (most of which 
don't support IPv6 hardly at all).



No, we're not putting ERX's at people's homes ... not sure where you got
that from?   What I was saying is that if you're running PPPOE then you have
have somewhere in the service provider network to "terminate" the
sessions

Paul

Re: IPv6: numbering of point-to-point-links

[ML]

On 1/24/2011 4:20 PM, Ray Soucy wrote:


That said.  By not using the 64-bit boundary you may be sacrificing
performance optimizations with today's processors that lack operations
for values larger than 64-bits.



Is this an issue for any known vendors today?

RE: PPPOE vs DHCP

[Paul Stewart]

Thank you for the response...

I should have made this a bit clearer - option 82 is an option on their
DSLAM's today and is supposed to work "not bad".  But this customer may also
be looking at other services such as wireless in the future which does not
support option 82 - they want a unified delivery of their product.  I left
out this detail as you can see ;)

Also, the comment " so a customer doesn't have to configure his/her router
to get online" is also interesting - we WANT our customers to configure
their routers and understand them to a basic degree... this coming from a
security perspective where we are seeing a magnitude to customer routers
getting hacked or their wireless left open etc.

Usage based billing is a very hot topic in this area (Ontario, Canada) and
we will confirm with the customer today that they do indeed want to track
all GB usage per customer... 

Today, they have no interest nor can they get IPv6 which is a shame
having said that, we want to provide a solution to them than can do IPv6 in
the future...

Thanks,

Paul


-Original Message-
From: Miquel van Smoorenburg [mailto:mik...@xs4all.net] 
Sent: Wednesday, January 26, 2011 4:16 AM
To: p...@paulstewart.org
Cc: nanog@nanog.org
Subject: Re: PPPOE vs DHCP

In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
>PPPOE vs DHCP
>Allows full authentication of customers (requires username/password)

You probably want to authenticate on circuit id, not username/password.
ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added
by the DSLAM or FTTH access switch when using an ethernet transport layer.
It's just a different radius attribute to authenticate on, no magic.
We do that so a customer doesn't have to configure his/her router
to get online.

>Easily assign static IP to customer (no MAC address or CPE information
>required)

Don't need that with DHCP either, if you run a DHCP server that can
assign IP addresses based on option82. I run a patched ISC dhcp3 server,
but I understand that ISC dhcp4 makes this pretty easy

>Assign public subnet to customer with ease (no manual routing required)

Don't need manual routing with DHCP either, if you use a real
bras such as a juniper, since you can have it authenticate off
radius first before doing DHCP, and in the radius reply you can
return a static route.

>Usage tracking (GB transfer) from radius generated data

True, at least juniper e-series BRASes don't send radius accounting
for atm rfc1483/bridged connections for some reason.

>DHCP Cons
>
>-

One more DHCP con is that if you have an ethernet transport network
from the DSLAM or FTTH access switch to your router that lumps together 
multiple customers in one VLAN, something along the way is probably
doing DHCP sniffing to set up routing. And you can be just about sure
that won't work with IPv6. VLAN-per-customer will work (and is a
really a great model, for all types of encapsulation)

Mike.

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Richard Barnes]

Could you elaborate?  Which circumstances?

On Wed, Jan 26, 2011 at 4:23 AM, Owen DeLong  wrote:
> It works for routing native IPv6 under some circumstances as well.
>
> Owen
>
> On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote:
>
>>
>>
>>
>> On Wed, 26 Jan 2011, Franck Martin wrote:
>>
>>> What about an Airport Extreme? It has a wan interface that does PPPOE
>>>
>>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic 
>>> IPv6 firewall.
>>
>> Yes it is. I already reported to Marco.
>> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey
>>
>> It should be included somehow in a matrix But 6to4 (or other tunneling 
>> techniques) is only a substitute of real IPv6.
>>
>> Regards,
>>       Janos Mohacsi
>>
>>>
>>> - Original Message -
>>> From: "Mirjam Kuehne" 
>>> To: nanog@nanog.org
>>> Sent: Tuesday, 25 January, 2011 3:34:14 AM
>>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
>>>
>>> [apologies for duplicates]
>>>
>>> Hello,
>>>
>>> Based on new information we received since the last publication, we
>>> updated the IPv6 CPE matrix:
>>>
>>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
>>>
>>> In order to make this information more useful for a large user base, we
>>> are preparing a detailed survey to gather more structural feedback about
>>> the range of equipment that is currently in use. Not only would we like
>>> you to participate in this survey, but we also ask for your help in
>>> identifying the right survey questions. Please find a call for input on
>>> RIPE Labs:
>>>
>>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed
>>>
>>> Kind Regards,
>>> Mirjam Kuehne & Marco Hogewoning
>>> RIPE NCC
>>>
>>>
>>>
>
>
>

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Roland Dobbins]

On Jan 26, 2011, at 6:29 PM, Eugen Leitl wrote:

> In practice you'd aim for ~um resolution for all major gravity wells in this 
> system (DTN is already flying, there's a Cisco box in Earth orbit, Moon and 
> Mars are next).

Don't forget the asteroid belt, that's where the real money is.


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Eugen Leitl]

On Wed, Jan 26, 2011 at 01:33:05AM +, Nathan Eisenberg wrote:
> > Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths 
> > of the
> > initial /3 delegated to unicast space by IETF. There are 6+ more /3s 
> > remaining
> > in the IETF pool.
> 
> That's good news - we need to make sure we have a /3 for both the Moon and 
> Mars colonies.  ;)

A /64 is barely enough bits for a ~2 m resolution on Earth surface, and
barely to the Karman line. In practice you'd aim for ~um resolution for all
major gravity wells in this system (DTN is already flying, there's
a Cisco box in Earth orbit, Moon and Mars are next).

(And of course if you're you're going to multiply above by 10^11, 
or so. Eventually).

RE: PPPOE vs DHCP

[Paul Stewart]

I just wanted to say thank you for a TONNE of feedback I received on this
topic.  This has been of great help in filling in some items I missed in my
quick list.

Will try to respond offlist to several of you that responded - got over 100
replies offline with some interesting ideas.  I definitely learned I should
have made my original post a bit clearer though and specifically the usage
tracking component ;)

Normally I would post a summary on these kinds of topics but quite honestly
there is such a huge varience in opinions and options around this that I'll
probably just invite anyone to hit me offlist if they are interested in the
feedback received so far...


Thanks folks,

Paul

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Owen DeLong]

It works for routing native IPv6 under some circumstances as well.

Owen

On Jan 26, 2011, at 12:01 AM, Mohacsi Janos wrote:

> 
> 
> 
> On Wed, 26 Jan 2011, Franck Martin wrote:
> 
>> What about an Airport Extreme? It has a wan interface that does PPPOE
>> 
>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 
>> firewall.
> 
> Yes it is. I already reported to Marco.
> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey
> 
> It should be included somehow in a matrix But 6to4 (or other tunneling 
> techniques) is only a substitute of real IPv6.
> 
> Regards,
>   Janos Mohacsi
> 
>> 
>> - Original Message -
>> From: "Mirjam Kuehne" 
>> To: nanog@nanog.org
>> Sent: Tuesday, 25 January, 2011 3:34:14 AM
>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
>> 
>> [apologies for duplicates]
>> 
>> Hello,
>> 
>> Based on new information we received since the last publication, we
>> updated the IPv6 CPE matrix:
>> 
>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
>> 
>> In order to make this information more useful for a large user base, we
>> are preparing a detailed survey to gather more structural feedback about
>> the range of equipment that is currently in use. Not only would we like
>> you to participate in this survey, but we also ask for your help in
>> identifying the right survey questions. Please find a call for input on
>> RIPE Labs:
>> 
>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed
>> 
>> Kind Regards,
>> Mirjam Kuehne & Marco Hogewoning
>> RIPE NCC
>> 
>> 
>> 

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Marco Hogewoning]

Hi,

Maybe a bit more to explain. Up to now I asked the vendors to provide certain 
information before adding a box to the matrix. Apple was send a copy but they 
never responded. In future we are going to build the matrix upon user supplied 
data. See the article on the future of this work at 
http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed.

What we'll probably do is include everything for which there is a minimum 
number of responses like 5 or 10. Actual number to be decided upon once this is 
rolling and we can figure out the relevant number is.

Grtx,

Marco

On Jan 26, 2011, at 8:01 AM, Mohacsi Janos wrote:

> 
> 
> 
> On Wed, 26 Jan 2011, Franck Martin wrote:
> 
>> What about an Airport Extreme? It has a wan interface that does PPPOE
>> 
>> The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 
>> firewall.
> 
> Yes it is. I already reported to Marco.
> http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey
> 
> It should be included somehow in a matrix But 6to4 (or other tunneling 
> techniques) is only a substitute of real IPv6.
> 
> Regards,
>   Janos Mohacsi
> 
>> 
>> - Original Message -
>> From: "Mirjam Kuehne" 
>> To: nanog@nanog.org
>> Sent: Tuesday, 25 January, 2011 3:34:14 AM
>> Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
>> 
>> [apologies for duplicates]
>> 
>> Hello,
>> 
>> Based on new information we received since the last publication, we
>> updated the IPv6 CPE matrix:
>> 
>> http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011
>> 
>> In order to make this information more useful for a large user base, we
>> are preparing a detailed survey to gather more structural feedback about
>> the range of equipment that is currently in use. Not only would we like
>> you to participate in this survey, but we also ask for your help in
>> identifying the right survey questions. Please find a call for input on
>> RIPE Labs:
>> 
>> http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed
>> 
>> Kind Regards,
>> Mirjam Kuehne & Marco Hogewoning
>> RIPE NCC
>> 
>> 
>> 
> 

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Owen DeLong]

On Jan 25, 2011, at 10:30 PM, Fernando Gont wrote:

> On 24/01/2011 05:53 p.m., Ray Soucy wrote:
>> Every time I see this question it' usually related to a fundamental
>> misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
>> 
>> That said.  Any size prefix will likely work and is even permitted by
>> the RFC.  You do run the risk of encountering applications that assume
>> a 64-bit prefix length, though.  And you're often crippling the
>> advantages of IPv6.
> 
> Just curious: What are the advantages you're referring to?
> 
1.  Sparse addressing
2.  SLAAC
3.  RFC 4193 Privacy Addressing
4.  Never have to worry about "growing" a subnet to hold new machines.
5.  Universal subnet size, no surprises, no operator confusion, no bitmath.

There are probably others.

Owen

Re: PPPOE vs DHCP

[Miquel van Smoorenburg]

In article <051001cbbcf0$c33e8b20$49bba160$@org> you write:
>PPPOE vs DHCP
>Allows full authentication of customers (requires username/password)

You probably want to authenticate on circuit id, not username/password.
ATM port/vpi/vci for ATM connections, or PPPoE circuit id tag added
by the DSLAM or FTTH access switch when using an ethernet transport layer.
It's just a different radius attribute to authenticate on, no magic.
We do that so a customer doesn't have to configure his/her router
to get online.

>Easily assign static IP to customer (no MAC address or CPE information
>required)

Don't need that with DHCP either, if you run a DHCP server that can
assign IP addresses based on option82. I run a patched ISC dhcp3 server,
but I understand that ISC dhcp4 makes this pretty easy

>Assign public subnet to customer with ease (no manual routing required)

Don't need manual routing with DHCP either, if you use a real
bras such as a juniper, since you can have it authenticate off
radius first before doing DHCP, and in the radius reply you can
return a static route.

>Usage tracking (GB transfer) from radius generated data

True, at least juniper e-series BRASes don't send radius accounting
for atm rfc1483/bridged connections for some reason.

>DHCP Cons
>
>-

One more DHCP con is that if you have an ethernet transport network
from the DSLAM or FTTH access switch to your router that lumps together 
multiple customers in one VLAN, something along the way is probably
doing DHCP sniffing to set up routing. And you can be just about sure
that won't work with IPv6. VLAN-per-customer will work (and is a
really a great model, for all types of encapsulation)

Mike.

Re: Another v6 question

[Michiel Klaver]

At 22-07-28164 20:59, Max Pierson wrote:

> From the provider perspective, what is the prefix-length that most are
accepting to be injected into your tables??  2 or so years ago, I read where
someone stated that they were told by ATT that they weren't planning on
accepting anything smaller than a /32. So what if I get my shiny new /48
from ARIN and am already multi-homed??? Does ATT not want my business (which
they wouldn't get if the first place, but for argument sake, yes, I chose to
pick on ATT, sorry if I offended anyone :)  I already see /40's /48's ,etc
in the v6 table, so some folks are allowing /48 and smaller, so what is the
new /24 in v6?



Hi Max,

There is a Wikipedia article all about that:
http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers 



And here is some more information about subnetting your IPv6 network:
http://en.wikipedia.org/wiki/IPv6_subnetting_reference

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Owen DeLong]

On Jan 25, 2011, at 9:49 PM, Roland Dobbins wrote:

> 
> On Jan 26, 2011, at 12:33 PM, Mark Smith wrote:
> 
>> The correct assumption is that most people will try and usually succeed at 
>> follow the specifications, as that is what is required to
>> successfully participate in a protocol (any protocol, not just networking 
>> ones). IPv4 history has shown that most people will.
> 
> Specification <> application, as in new applications.
> 
> And, no, I don't think that 'most people will' - I've seen enough foolishness 
> with regards to IPv4 misaddressing over the last quarter-century (pre- and 
> post-CIDR) to share your optimism in that regard.
> 
Is there IPv4 brokenness in the world? Sure.

Is the majority of IPv4 deployed in the world done so in a broken manner? I 
think that's a stretch.

Most people try and usually succeed at implementing IPv4 at least reasonably in 
line with the specifications.

Owen

Re: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[Mohacsi Janos]

On Wed, 26 Jan 2011, Franck Martin wrote:


What about an Airport Extreme? It has a wan interface that does PPPOE

The IPv6 feature seems working, with 6to4 or static tunnels and a basic IPv6 
firewall.


Yes it is. I already reported to Marco.
http://labs.ripe.net/Members/marco/content-ipv6-cpe-survey

It should be included somehow in a matrix But 6to4 (or other tunneling 
techniques) is only a substitute of real IPv6.


Regards,
Janos Mohacsi



- Original Message -
From: "Mirjam Kuehne" 
To: nanog@nanog.org
Sent: Tuesday, 25 January, 2011 3:34:14 AM
Subject: Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed

[apologies for duplicates]

Hello,

Based on new information we received since the last publication, we
updated the IPv6 CPE matrix:

http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011

In order to make this information more useful for a large user base, we
are preparing a detailed survey to gather more structural feedback about
the range of equipment that is currently in use. Not only would we like
you to participate in this survey, but we also ask for your help in
identifying the right survey questions. Please find a call for input on
RIPE Labs:

http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed

Kind Regards,
Mirjam Kuehne & Marco Hogewoning
RIPE NCC