From thedarkone at list.ru  Sat Jan  2 18:47:19 2010
From: thedarkone at list.ru (The Dark One)
Date: Sat, 02 Jan 2010 20:47:19 +0300
Subject: IPv4 Embedded IPv6 Unicast
Message-ID: <E1NR84N-0000BM-00.thedarkone-list-ru@f289.mail.ru>

Experts,
Junos accepts the following notation, very handy sometimes; do you know the exact official name for this kind of notation:

unit 0 {
    family inet {
        address 10.10.20.34/24;
    }
    family inet6 {
        address 2001:1111:2222:3333::10.10.20.34/64;
    }
}

Thanks!

From nick-lists at netability.ie  Sat Jan  2 19:13:47 2010
From: nick-lists at netability.ie (Nick Hilliard)
Date: Sat, 02 Jan 2010 18:13:47 +0000
Subject: IPv4 Embedded IPv6 Unicast
In-Reply-To: <E1NR84N-0000BM-00.thedarkone-list-ru@f289.mail.ru>
References: <E1NR84N-0000BM-00.thedarkone-list-ru@f289.mail.ru>
Message-ID: <4B3F8CDB.8050906@netability.ie>

On 02/01/2010 17:47, The Dark One wrote:
> Experts,
> Junos accepts the following notation, very handy sometimes; do you know the exact official name for this kind of notation:
[...]
>         address 2001:1111:2222:3333::10.10.20.34/64;

"legacy view"?  "messed up mode"?  "let's-pretend-we're-still-using-ipv4
notation"? :-)

See RFC 2373, section 2.2 (Text Representation of Addresses) for more
information.  There appears not to be an official name for this textual
representation.

Nick

From skoal at skoal.name  Sat Jan  2 21:26:39 2010
From: skoal at skoal.name (Gergely Antal)
Date: Sat, 2 Jan 2010 21:26:39 +0100
Subject: IPv4 Embedded IPv6 Unicast
In-Reply-To: <4B3F8CDB.8050906@netability.ie>
References: <E1NR84N-0000BM-00.thedarkone-list-ru@f289.mail.ru>
	<4B3F8CDB.8050906@netability.ie>
Message-ID: <20100102212639.38e01cd7@roadrunner.skoal.name>

On Sat, 02 Jan 2010 18:13:47 +0000
Nick Hilliard <nick-lists at netability.ie> wrote:

> On 02/01/2010 17:47, The Dark One wrote:
> > Experts,
> > Junos accepts the following notation, very handy sometimes; do you
> > know the exact official name for this kind of notation:
> [...]
> >         address 2001:1111:2222:3333::10.10.20.34/64;
> 
> "legacy view"?  "messed up mode"?
> "let's-pretend-we're-still-using-ipv4 notation"? :-)
> 
> See RFC 2373, section 2.2 (Text Representation of Addresses) for more
> information.  There appears not to be an official name for this
> textual representation.
> 
> Nick

Isn't this called v4inv6 ? 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100102/8b78be73/attachment.bin 

From nick-lists at netability.ie  Sat Jan  2 21:51:34 2010
From: nick-lists at netability.ie (Nick Hilliard)
Date: Sat, 02 Jan 2010 20:51:34 +0000
Subject: IPv4 Embedded IPv6 Unicast
In-Reply-To: <20100102212639.38e01cd7@roadrunner.skoal.name>
References: <E1NR84N-0000BM-00.thedarkone-list-ru@f289.mail.ru>	<4B3F8CDB.8050906@netability.ie>
	<20100102212639.38e01cd7@roadrunner.skoal.name>
Message-ID: <4B3FB1D6.7080805@netability.ie>

On 02/01/2010 20:26, Gergely Antal wrote:
> Isn't this called v4inv6 ? 

doesn't that refer to tunnelling rather than naming?

Nick


From bit.gossip at chello.nl  Sun Jan  3 22:17:30 2010
From: bit.gossip at chello.nl (Bit Gossip)
Date: Sun, 03 Jan 2010 22:17:30 +0100
Subject: net.ipv6.conf.all.send_redirects
Message-ID: <1262553450.2133.5.camel@localhost>

Experts,
in IPv4 it was possible to disable sending ICMP redirect as simple as:

# sysctl -w net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.send_redirects = 0

Unfortunately the same key seems to have disappeared in IPv6:

# sysctl -w net.ipv6.conf.all.send_redirects=0
error: "net.ipv6.conf.all.send_redirects" is an unknown key

Any idea how to disable sending ICMP redirect?
Thanks!


From gbonser at seven.com  Sun Jan  3 23:24:42 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 3 Jan 2010 14:24:42 -0800
Subject: net.ipv6.conf.all.send_redirects
In-Reply-To: <1262553450.2133.5.camel@localhost>
References: <1262553450.2133.5.camel@localhost>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F712F@RWC-EX1.corp.seven.com>

> -----Original Message-----
> From: ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de [mailto:ipv6-
> ops-bounces+gbonser=seven.com at lists.cluenet.de] On Behalf Of Bit Gossip
> Sent: Sunday, January 03, 2010 1:18 PM
> To: ipv6-ops at lists.cluenet.de
> Subject: net.ipv6.conf.all.send_redirects
> 
> Experts,
> in IPv4 it was possible to disable sending ICMP redirect as simple as:
> 
> # sysctl -w net.ipv4.conf.all.send_redirects=0
> net.ipv4.conf.all.send_redirects = 0
> 
> Unfortunately the same key seems to have disappeared in IPv6:
> 
> # sysctl -w net.ipv6.conf.all.send_redirects=0
> error: "net.ipv6.conf.all.send_redirects" is an unknown key
> 
> Any idea how to disable sending ICMP redirect?
> Thanks!


It is my understanding that redirects are sent only if the unit is a router and the protocol spec says that if a unit is a router than it MUST support the sending of redirects ( RFC4294 ?4.2 )

So if you turn off redirects on an IPv6 router, you have broken IPv6.  In other words, in IPv6, redirects are not optional in sending according to the RFC.





From kiwi at oav.net  Sun Jan  3 23:53:54 2010
From: kiwi at oav.net (Xavier Beaudouin)
Date: Sun, 3 Jan 2010 23:53:54 +0100
Subject: net.ipv6.conf.all.send_redirects
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F712F@RWC-EX1.corp.seven.com>
References: <1262553450.2133.5.camel@localhost>
	<5A6D953473350C4B9995546AFE9939EE081F712F@RWC-EX1.corp.seven.com>
Message-ID: <FBBA36E8-2BD8-433A-9C07-7B05EFDECFCD@oav.net>

Hi there,

Le 3 janv. 2010 ? 23:24, George Bonser a ?crit :

>> -----Original Message-----
>> From: ipv6-ops-bounces+gbonser=seven.com at lists.cluenet.de [mailto:ipv6-
>> ops-bounces+gbonser=seven.com at lists.cluenet.de] On Behalf Of Bit Gossip
>> Sent: Sunday, January 03, 2010 1:18 PM
>> To: ipv6-ops at lists.cluenet.de
>> Subject: net.ipv6.conf.all.send_redirects
>> 
>> Experts,
>> in IPv4 it was possible to disable sending ICMP redirect as simple as:
>> 
>> # sysctl -w net.ipv4.conf.all.send_redirects=0
>> net.ipv4.conf.all.send_redirects = 0
>> 
>> Unfortunately the same key seems to have disappeared in IPv6:
>> 
>> # sysctl -w net.ipv6.conf.all.send_redirects=0
>> error: "net.ipv6.conf.all.send_redirects" is an unknown key
>> 
>> Any idea how to disable sending ICMP redirect?
>> Thanks!
> 
> 
> It is my understanding that redirects are sent only if the unit is a router and the protocol spec says that if a unit is a router than it MUST support the sending of redirects ( RFC4294 ?4.2 )
> 
> So if you turn off redirects on an IPv6 router, you have broken IPv6.  In other words, in IPv6, redirects are not optional in sending according to the RFC.

On my OpenBSD routers I have :

net.inet6.icmp6.rediraccept=1

But as says George, it is better to leave this on...

/Xavier

From gbonser at seven.com  Mon Jan  4 04:00:46 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 3 Jan 2010 19:00:46 -0800
Subject: net.ipv6.conf.all.send_redirects
In-Reply-To: <FBBA36E8-2BD8-433A-9C07-7B05EFDECFCD@oav.net>
References: <1262553450.2133.5.camel@localhost>
	<5A6D953473350C4B9995546AFE9939EE081F712F@RWC-EX1.corp.seven.com>
	<FBBA36E8-2BD8-433A-9C07-7B05EFDECFCD@oav.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7130@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: Xavier Beaudouin [mailto:kiwi at oav.net]
> Sent: Sunday, January 03, 2010 2:54 PM
> To: George Bonser
> Cc: Bit Gossip; ipv6-ops at lists.cluenet.de
> Subject: Re: net.ipv6.conf.all.send_redirects
> 
> 
> On my OpenBSD routers I have :
> 
> net.inet6.icmp6.rediraccept=1
> 
> But as says George, it is better to leave this on...
> 
> /Xavier

Accept_redirects is one thing, we were discussing send_redirects.

Linux has an accept_redirects switch where you can turn that behavior on
or off but there isn't one for send_redirects as there is in ipv4.





From tore.anderson at redpill-linpro.com  Mon Jan  4 11:43:31 2010
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Mon, 04 Jan 2010 11:43:31 +0100
Subject: IPv6 brokenness in Norway, Dec 2009
Message-ID: <4B41C653.3040908@redpill-linpro.com>

Hi and a happy new year to all of you,

I've attached a new set of numbers from December of my IPv6 brokenness
experiment.  Brokenness has gone down dramatically compared to November
(from 0.217% to 0.140%), it seems like something happened on the 25th of
November that improved things.  I have not yet tried to figure out
exactly what that was - perhaps a broken 6to4 or Teredo relay somewhere
got fixed?

When excluding Opera the numbers have also gone down slightly (from
0.023% to 0.018%), but looking at the dates it seems that this is an
effect of the holidays - perhaps due to students leaving their
dormitories (whose networks are known to filter 6to4).

Opera has promised me that the next update to their stable 10.1x branch,
due to be released early this year, will make it so that IPv4 is
preferred over IPv6 if the local v6 source address is within the Teredo
or 6to4 prefixes.  I'm crossing my fingers that they'll keep their word.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 200912.txt
Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100104/857d73de/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 200912-noopera.txt
Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100104/857d73de/attachment-0001.txt 

From me at benedikt-stockebrand.de  Sat Jan  2 12:45:35 2010
From: me at benedikt-stockebrand.de (Benedikt Stockebrand)
Date: Sat, 02 Jan 2010 11:45:35 +0000
Subject: anycast address as deault router
In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7A2C@ad-exh01.adhost.lan>
	(Michael K. Smith's message of "Wed, 30 Dec 2009 13:33:22 -0800")
References: <E1NQ637-000319-00.thedarkone-list-ru@f252.mail.ru>
	<4B3BC646.8050700@netability.ie>
	<17838240D9A5544AAA5FF95F8D520316074E7A2C@ad-exh01.adhost.lan>
Message-ID: <sa7pr5sg274.fsf@benedikt-stockebrand.de>

Hello everybody,

"Michael K. Smith - Adhost" <mksmith at adhost.com> writes:

>> On 30/12/2009 21:25, The Dark One wrote:
>> > supposing that on a LAN there are 2 routers (default-gateway) and
> one
>> > host and that the routers don't support any
>> FirstHopRedundancyProtocol,
>> > does it make sense to configure a anycast address on both routers
> and
>> > configure that as the default-gateway of the host?

Yes, but... see below.

>> > If it does makes sense, is it also possible to have the routers
>> > advertise that anycast address in their RA?

Not as far as I know; there is no explicit router address field in a
Router Advertisement; instead the source address of the packet is
used, which must be a link-local address.  If you find a way to
configure your router with an extra anycast link-local address and
then make it use that address for its router advertisements, then it
might work, at least as far as I understand the standards.  I have
some doubts if this is actually works on existing implementations,
though.

Neither do I consider it a particularly good idea---see below for
alternatives.

>> Sounds like this would fall foul of duplicate address detection.  I
>> suspect
>> both your routers and your leaf nodes would probably get very excited
>> about
>> this, and not necessarily in a good way either.

There shouldn't be any problem: Configuring an address as anycast
disables Duplicate Address Detection, so it shouldn't be an issue on
the router side.  As of RFC 4862, 5.4 (p. 12): "Duplicate Address
Detection MUST NOT be performed on anycast addresses (note that
anycast addresses cannot syntactically be distinguished from unicast
addresses)."

And the hosts should play along simply because otherwise anycast as
such wouldn't work.

That doesn't mean that I consider the idea any better at this point...

>> By all means try it out, but when it refuses to work, take a look at
>> RFC2462 (section 5.4).

(RFC 2462 has been obsoleted by 4862 but this part seems to be
unchanged except for some clarifications.)

> I had to do exactly this on my GSR's because they don't support RA
> prioritization or HSRP v3 and most likely never will.  The anycasted
> default gateway from two routers does work, although the failover
> between routers is +/- 20 seconds.  If anyone would like a copy of the
> configuration snippets just let me know.

I think that Neighbor/Router Discovery is still the way to go.  It
just takes a bit of tuning:

- According to RFC4861 it is possible to update the Neighbor Discovery
  timeouts through the Reachable Time field in a Router Advertisement,
  speeding up timeouts significantly at the price of potentially more
  ND traffic.

- If that doesn't work: The timeouts may be configurable on the host,
  depending on the particular implementation.

- As of RFC 4191, Router Discovery has been extended to support router
  preferences, allowing for the definition if a "``default'' default
  router".

Using these features it should be possible to do away with HSRP and
such since hosts will switch to the surviving router if their "active"
one goes off-link.  See RFCs 4191, 4311 and 4861 for the protocol
details.

So far I haven't found the time to check existing implementations for
these features, so I suggest you do some thorough testing before you
go live with them.


Alternatively, if you are really desperate for sub-second failover,
consider reconfiguring your host as a router and running OSPF between
it and the routers.  (Sorry if you are running EIGRP in a "Cisco only"
setup...)


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.


From me at benedikt-stockebrand.de  Sun Jan  3 21:12:38 2010
From: me at benedikt-stockebrand.de (Benedikt Stockebrand)
Date: Sun, 03 Jan 2010 20:12:38 +0000
Subject: IPv4 Embedded IPv6 Unicast
In-Reply-To: <20100102212639.38e01cd7@roadrunner.skoal.name> (Gergely
	Antal's message of "Sat, 2 Jan 2010 21:26:39 +0100")
References: <E1NR84N-0000BM-00.thedarkone-list-ru@f289.mail.ru>
	<4B3F8CDB.8050906@netability.ie>
	<20100102212639.38e01cd7@roadrunner.skoal.name>
Message-ID: <sa7hbr3gd6x.fsf@benedikt-stockebrand.de>

Hello everybody,

Gergely Antal <skoal at skoal.name> writes:

> On Sat, 02 Jan 2010 18:13:47 +0000
> Nick Hilliard <nick-lists at netability.ie> wrote:
>
>> On 02/01/2010 17:47, The Dark One wrote:
>> > Experts,
>> > Junos accepts the following notation, very handy sometimes; do you
>> > know the exact official name for this kind of notation:
>> [...]
>> >         address 2001:1111:2222:3333::10.10.20.34/64;
>> 
>> "legacy view"?  "messed up mode"?
>> "let's-pretend-we're-still-using-ipv4 notation"? :-)
>> 
>> See RFC 2373, section 2.2 (Text Representation of Addresses) for more
>> information.  There appears not to be an official name for this
>> textual representation.

The term I have most commonly heard is "mixed notation".  But as far
as I know, you are right there is no official name for it.

All applications should support this as long as they use the standard
address parsing library functions (getaddrinfo(3) and the like), so it
isn't much a surprise that JunOS handles it correctly.

> Isn't this called v4inv6 ? 

No.  The notation is primarily intended for the the "IPv6-compatible
IPv4 addresses" (::/96) used with the deprecated (as of RFC 4213)
"automatic 6in4 tunnels" (RFC 2893) and for the "IPv4-mapped IPv6
addresses" (::ffff:0:0/96, RFC 3493) that IPv4 traffic is mapped into
before it is passed to an IPv6-oriented application.

As far as I know "v4inv6" isn't considered standard terminology; there
are "4in6" (short for "IPv4-in-IPv6") tunnels but they don't use any
kind of computed address mapping.

What's slightly annoying about the mixed notation is that it *doesn't*
work the middle of an IPv6 address: "2002:192.0.2.41:4711::/64" would
be handy with 6to4 tunnels.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.


From spz at serpens.de  Mon Jan  4 23:33:49 2010
From: spz at serpens.de (S.P.Zeidler)
Date: Mon, 4 Jan 2010 23:33:49 +0100
Subject: net.ipv6.conf.all.send_redirects
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7130@RWC-EX1.corp.seven.com>
References: <1262553450.2133.5.camel@localhost>
	<5A6D953473350C4B9995546AFE9939EE081F712F@RWC-EX1.corp.seven.com>
	<FBBA36E8-2BD8-433A-9C07-7B05EFDECFCD@oav.net>
	<5A6D953473350C4B9995546AFE9939EE081F7130@RWC-EX1.corp.seven.com>
Message-ID: <20100104223348.GI19220@serpens.de>

Hi,

Thus wrote George Bonser (gbonser at seven.com):

> Accept_redirects is one thing, we were discussing send_redirects.
> 
> Linux has an accept_redirects switch where you can turn that behavior on
> or off but there isn't one for send_redirects as there is in ipv4.

This is all very much OS dependent. NetBSD has:
net.inet6.ip6.redirect = 1         	(sending)
net.inet6.icmp6.rediraccept = 1     (accepting)

The setting will of course do exactly nothing if the system in question
isn't forwarding.

I suspect other KAME based IPv6 stacks will have the same. 
Whether it's wise to disable sending redirect is left as an exercise for
the reader :-P

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)

From prox at prolixium.com  Tue Jan  5 04:50:39 2010
From: prox at prolixium.com (Mark Kamichoff)
Date: Mon, 4 Jan 2010 22:50:39 -0500
Subject: Google filtering ICMPv6 type 2?
Message-ID: <20100105035039.GB13664@prolixium.com>

Hi - 

I noticed today that HTTP requests to ipv6.google.com (and
www.google.com with Google-over-IPv6) seemed to be unusually laggy and
frequently timing out.  I looked a little deeper and saw that Google may
be inadvertently dropping ICMPv6 type 2 (packet too big) messages.  I'm
seeing things like this for TCP packets that are attempting to enter a
tunnel (MTU 1280) I have setup between me and a box of mine with native
IPv6 connectivity:

22:21:44.513137 IP6 2001:4860:800e::69.80 >
2001:48c8:1:105:219:d1ff:fe21:d70d.49530: . 1:1429(1428) ack 119 win 90
<nop,nop,timestamp 1528748730 1102342799>
22:21:44.513197 IP6 2001:48c8:1:2::2 > 2001:4860:800e::69: ICMP6, packet
too big, mtu 1280, length 1240
22:21:44.513263 IP6 2001:4860:800e::69.80 >
2001:48c8:1:105:219:d1ff:fe21:d70d.49530: . 1429:2857(1428) ack 119 win
90 <nop,nop,timestamp 1528748730 1102342799>
22:21:44.513298 IP6 2001:48c8:1:2::2 > 2001:4860:800e::69: ICMP6, packet
too big, mtu 1280, length 1240
22:21:44.513388 IP6 2001:4860:800e::69.80 >
2001:48c8:1:105:219:d1ff:fe21:d70d.49530: P 2857:4280(1423) ack 119 win
90 <nop,nop,timestamp 1528748730 1102342799>

Sorry if that's hard to read, the full packet capture is here:

http://www.prolixium.com/files/mynews/googleipv6.cap.txt

I've tested this from the above setup (in NYC) and from an HE tunnel to
Ashburn, VA.  Both experience similar issues.  However, I did another
test from a friend's box who has an HE tunnel to Chicago, IL, and didn't
see a problem.

Anyone else seeing this?  Perhaps Google put an erroneous filter on some
of their peering routers, but not others?

Hopefully it'll get yanked.  I'd hate to go back to IPv4 for searching
the web!

- Mark

-- 
Mark Kamichoff
prox at prolixium.com
http://www.prolixium.com/

From ek at google.com  Tue Jan  5 04:55:56 2010
From: ek at google.com (Erik Kline)
Date: Mon, 4 Jan 2010 19:55:56 -0800
Subject: Google filtering ICMPv6 type 2?
In-Reply-To: <20100105035039.GB13664@prolixium.com>
References: <20100105035039.GB13664@prolixium.com>
Message-ID: <2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>

2010/1/4 Mark Kamichoff <prox at prolixium.com>:
> Hi -
>
> I noticed today that HTTP requests to ipv6.google.com (and
> www.google.com with Google-over-IPv6) seemed to be unusually laggy and
> frequently timing out. ?I looked a little deeper and saw that Google may
> be inadvertently dropping ICMPv6 type 2 (packet too big) messages. ?I'm
> seeing things like this for TCP packets that are attempting to enter a
> tunnel (MTU 1280) I have setup between me and a box of mine with native
> IPv6 connectivity:
>
> 22:21:44.513137 IP6 2001:4860:800e::69.80 >
> 2001:48c8:1:105:219:d1ff:fe21:d70d.49530: . 1:1429(1428) ack 119 win 90
> <nop,nop,timestamp 1528748730 1102342799>
> 22:21:44.513197 IP6 2001:48c8:1:2::2 > 2001:4860:800e::69: ICMP6, packet
> too big, mtu 1280, length 1240
> 22:21:44.513263 IP6 2001:4860:800e::69.80 >
> 2001:48c8:1:105:219:d1ff:fe21:d70d.49530: . 1429:2857(1428) ack 119 win
> 90 <nop,nop,timestamp 1528748730 1102342799>
> 22:21:44.513298 IP6 2001:48c8:1:2::2 > 2001:4860:800e::69: ICMP6, packet
> too big, mtu 1280, length 1240
> 22:21:44.513388 IP6 2001:4860:800e::69.80 >
> 2001:48c8:1:105:219:d1ff:fe21:d70d.49530: P 2857:4280(1423) ack 119 win
> 90 <nop,nop,timestamp 1528748730 1102342799>
>
> Sorry if that's hard to read, the full packet capture is here:
>
> http://www.prolixium.com/files/mynews/googleipv6.cap.txt
>
> I've tested this from the above setup (in NYC) and from an HE tunnel to
> Ashburn, VA. ?Both experience similar issues. ?However, I did another
> test from a friend's box who has an HE tunnel to Chicago, IL, and didn't
> see a problem.
>
> Anyone else seeing this? ?Perhaps Google put an erroneous filter on some
> of their peering routers, but not others?
>
> Hopefully it'll get yanked. ?I'd hate to go back to IPv4 for searching
> the web!
>
> - Mark
>
> --
> Mark Kamichoff
> prox at prolixium.com
> http://www.prolixium.com/
>

This is an issue that's been reported and we're looking in to right
now.  Sometimes pMTUd works, sometimes not, as you note.  Hopefully
we'll have some useful fix soon.

-Erik

From ek at google.com  Tue Jan  5 05:04:24 2010
From: ek at google.com (Erik Kline)
Date: Mon, 4 Jan 2010 20:04:24 -0800
Subject: Google filtering ICMPv6 type 2?
In-Reply-To: <2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>
References: <20100105035039.GB13664@prolixium.com>
	<2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>
Message-ID: <2e8c64261001042004l3f2dfde4ke425b2458fd0c49b@mail.gmail.com>

2010/1/4 Erik Kline <ek at google.com>:
> 2010/1/4 Mark Kamichoff <prox at prolixium.com>:
>> Hi -
>>
>> I noticed today that HTTP requests to ipv6.google.com (and
>> www.google.com with Google-over-IPv6) seemed to be unusually laggy and
>> frequently timing out. ?I looked a little deeper and saw that Google may
>> be inadvertently dropping ICMPv6 type 2 (packet too big) messages. ?I'm
>> seeing things like this for TCP packets that are attempting to enter a
>> tunnel (MTU 1280) I have setup between me and a box of mine with native
>> IPv6 connectivity:
>>
>> 22:21:44.513137 IP6 2001:4860:800e::69.80 >
>> 2001:48c8:1:105:219:d1ff:fe21:d70d.49530: . 1:1429(1428) ack 119 win 90
>> <nop,nop,timestamp 1528748730 1102342799>
>> 22:21:44.513197 IP6 2001:48c8:1:2::2 > 2001:4860:800e::69: ICMP6, packet
>> too big, mtu 1280, length 1240
>> 22:21:44.513263 IP6 2001:4860:800e::69.80 >
>> 2001:48c8:1:105:219:d1ff:fe21:d70d.49530: . 1429:2857(1428) ack 119 win
>> 90 <nop,nop,timestamp 1528748730 1102342799>
>> 22:21:44.513298 IP6 2001:48c8:1:2::2 > 2001:4860:800e::69: ICMP6, packet
>> too big, mtu 1280, length 1240
>> 22:21:44.513388 IP6 2001:4860:800e::69.80 >
>> 2001:48c8:1:105:219:d1ff:fe21:d70d.49530: P 2857:4280(1423) ack 119 win
>> 90 <nop,nop,timestamp 1528748730 1102342799>
>>
>> Sorry if that's hard to read, the full packet capture is here:
>>
>> http://www.prolixium.com/files/mynews/googleipv6.cap.txt
>>
>> I've tested this from the above setup (in NYC) and from an HE tunnel to
>> Ashburn, VA. ?Both experience similar issues. ?However, I did another
>> test from a friend's box who has an HE tunnel to Chicago, IL, and didn't
>> see a problem.
>>
>> Anyone else seeing this? ?Perhaps Google put an erroneous filter on some
>> of their peering routers, but not others?
>>
>> Hopefully it'll get yanked. ?I'd hate to go back to IPv4 for searching
>> the web!
>>
>> - Mark
>>
>> --
>> Mark Kamichoff
>> prox at prolixium.com
>> http://www.prolixium.com/
>>
>
> This is an issue that's been reported and we're looking in to right
> now. ?Sometimes pMTUd works, sometimes not, as you note. ?Hopefully
> we'll have some useful fix soon.
>
> -Erik
>

I don't know you're exact setup but in the meantime you might set the
MTU in the RA for hosts behind that tunnel; that way they know their
correct MSS...

From prox at prolixium.com  Tue Jan  5 05:10:35 2010
From: prox at prolixium.com (Mark Kamichoff)
Date: Mon, 4 Jan 2010 23:10:35 -0500
Subject: Google filtering ICMPv6 type 2?
In-Reply-To: <2e8c64261001042004l3f2dfde4ke425b2458fd0c49b@mail.gmail.com>
References: <20100105035039.GB13664@prolixium.com>
	<2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>
	<2e8c64261001042004l3f2dfde4ke425b2458fd0c49b@mail.gmail.com>
Message-ID: <20100105041035.GC13664@prolixium.com>

Hi Erik - 

On Mon, Jan 04, 2010 at 08:04:24PM -0800, Erik Kline wrote:
> 2010/1/4 Erik Kline <ek at google.com>:
> > This is an issue that's been reported and we're looking in to right
> > now. ?Sometimes pMTUd works, sometimes not, as you note. ?Hopefully
> > we'll have some useful fix soon.

Great, thanks!

> I don't know you're exact setup but in the meantime you might set the
> MTU in the RA for hosts behind that tunnel; that way they know their
> correct MSS...

They're actually a few hops away from the tunnel in both test cases,
connected by GigE, so the MSS is correct for their local interfaces.  I
suppose I could change everything to 1280 on the links via radvd, but by
then I'm sure things will be long resolved.. :-)

- Mark

-- 
Mark Kamichoff
prox at prolixium.com
http://www.prolixium.com/

From ek at google.com  Tue Jan  5 05:20:01 2010
From: ek at google.com (Erik Kline)
Date: Mon, 4 Jan 2010 20:20:01 -0800
Subject: Google filtering ICMPv6 type 2?
In-Reply-To: <20100105041035.GC13664@prolixium.com>
References: <20100105035039.GB13664@prolixium.com>
	<2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>
	<2e8c64261001042004l3f2dfde4ke425b2458fd0c49b@mail.gmail.com>
	<20100105041035.GC13664@prolixium.com>
Message-ID: <2e8c64261001042020t65a2b840g5ab06f13c5d90f1d@mail.gmail.com>

>> I don't know you're exact setup but in the meantime you might set the
>> MTU in the RA for hosts behind that tunnel; that way they know their
>> correct MSS...
>
> They're actually a few hops away from the tunnel in both test cases,
> connected by GigE, so the MSS is correct for their local interfaces. ?I
> suppose I could change everything to 1280 on the links via radvd, but by
> then I'm sure things will be long resolved.. :-)

Right.  And we could force 1280 on our end, with the same result.  The
general feeling at the moment is that if we can get/keep pMTUd working
then that's better than just clamping everything at 1280.

From me at benedikt-stockebrand.de  Tue Jan  5 13:00:21 2010
From: me at benedikt-stockebrand.de (Benedikt Stockebrand)
Date: Tue, 05 Jan 2010 12:00:21 +0000
Subject: Google filtering ICMPv6 type 2?
In-Reply-To: <2e8c64261001042020t65a2b840g5ab06f13c5d90f1d@mail.gmail.com>
	(Erik Kline's message of "Mon, 4 Jan 2010 20:20:01 -0800")
References: <20100105035039.GB13664@prolixium.com>
	<2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>
	<2e8c64261001042004l3f2dfde4ke425b2458fd0c49b@mail.gmail.com>
	<20100105041035.GC13664@prolixium.com>
	<2e8c64261001042020t65a2b840g5ab06f13c5d90f1d@mail.gmail.com>
Message-ID: <sa7zl4s69t6.fsf@benedikt-stockebrand.de>

Hello everybody,

Erik Kline <ek at google.com> writes:

>>> I don't know you're exact setup but in the meantime you might set the
>>> MTU in the RA for hosts behind that tunnel; that way they know their
>>> correct MSS...

there was a discussion on a similar approach to this on a (near dead)
German IPv6 list.  Conclusion: DON'T (sorry for the shouting).

Path MTU Discovery problems are already quite misleading in nature and
as such difficult enough to diagnose and even more difficult to
resolve.  Wantonly clamping down MTUs will only make these tasks
worse.

Strategically even more important, once we go down that path we're
quickly at the point that this approach becomes a "standard procedure"
and it becomes "your fault" if something breaks "because you
configured a non-standard MTU" (i.e. one larger than 1280).

>> They're actually a few hops away from the tunnel in both test cases,
>> connected by GigE, so the MSS is correct for their local interfaces. ??I
>> suppose I could change everything to 1280 on the links via radvd, but by
>> then I'm sure things will be long resolved.. :-)
>
> Right.  And we could force 1280 on our end, with the same result.  The
> general feeling at the moment is that if we can get/keep pMTUd working
> then that's better than just clamping everything at 1280.

For this to work you have to do it on both sides.  If the server side
does but the client doesn't then all that will happen is that "small"
HTTP requests (with the HTTP request fitting within a packet smaller
than the actual pMTU) work but "large" ones won't.

Now have somebody call this an application problem and all sorts of
developers will start to search for a bug that's not in their code at
all.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.


From kiwi at oav.net  Tue Jan  5 15:26:41 2010
From: kiwi at oav.net (Xavier Beaudouin)
Date: Tue, 05 Jan 2010 15:26:41 +0100
Subject: /127 between =?UTF-8?Q?routers=3F?=
Message-ID: <3954fbd030775be32711bd3404a349ef@127.0.0.1>

Hi there...

I can't figure if there is any drawback to use a /64 and subnet it into
/127 only for point to point connections between routers.

Seems that OpenBSD doesn't forbid that, but I wanted to know if there is
any drawback in this way of connection each routers in such way.

When I was working on 2000 and have 6bone stuff and was pTLA, we cannot do
that, now KAME stack on OpenBSD allow that.

Any good practices in this domain ?

Xavier

-- 
Association KAZAR - http://kazar.net/
Non profit hosting for anybody in France

From mohacsi at niif.hu  Tue Jan  5 15:29:31 2010
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Tue, 5 Jan 2010 15:29:31 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
Message-ID: <alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>

Hi,

 	Have a look at RFC 3627:
http://tools.ietf.org/html/rfc3627
"Use of /127 Prefix Length Between Routers Considered Harmful"

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Tue, 5 Jan 2010, Xavier Beaudouin wrote:

> Hi there...
>
> I can't figure if there is any drawback to use a /64 and subnet it into
> /127 only for point to point connections between routers.
>
> Seems that OpenBSD doesn't forbid that, but I wanted to know if there is
> any drawback in this way of connection each routers in such way.
>
> When I was working on 2000 and have 6bone stuff and was pTLA, we cannot do
> that, now KAME stack on OpenBSD allow that.
>
> Any good practices in this domain ?
>
> Xavier
>
> -- 
> Association KAZAR - http://kazar.net/
> Non profit hosting for anybody in France
>

From swmike at swm.pp.se  Tue Jan  5 15:30:06 2010
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 5 Jan 2010 15:30:06 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
Message-ID: <alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>

On Tue, 5 Jan 2010, Xavier Beaudouin wrote:

> Hi there...
>
> I can't figure if there is any drawback to use a /64 and subnet it into
> /127 only for point to point connections between routers.
>
> Seems that OpenBSD doesn't forbid that, but I wanted to know if there is
> any drawback in this way of connection each routers in such way.
>
> When I was working on 2000 and have 6bone stuff and was pTLA, we cannot do
> that, now KAME stack on OpenBSD allow that.
>
> Any good practices in this domain ?

People seem to mostly use /126, /112 or /64 for their p-t-p links.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From mohacsi at niif.hu  Tue Jan  5 15:33:05 2010
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Tue, 5 Jan 2010 15:33:05 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
Message-ID: <alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>

Also:
http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt


Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Tue, 5 Jan 2010, Mohacsi Janos wrote:

> Hi,
>
> 	Have a look at RFC 3627:
> http://tools.ietf.org/html/rfc3627
> "Use of /127 Prefix Length Between Routers Considered Harmful"
>
> Janos Mohacsi
> Head of HBONE+ project
> Network Engineer, Deputy Director of Network Planning and Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
>
> On Tue, 5 Jan 2010, Xavier Beaudouin wrote:
>
>> Hi there...
>> 
>> I can't figure if there is any drawback to use a /64 and subnet it into
>> /127 only for point to point connections between routers.
>> 
>> Seems that OpenBSD doesn't forbid that, but I wanted to know if there is
>> any drawback in this way of connection each routers in such way.
>> 
>> When I was working on 2000 and have 6bone stuff and was pTLA, we cannot do
>> that, now KAME stack on OpenBSD allow that.
>> 
>> Any good practices in this domain ?
>> 
>> Xavier
>> 
>> -- 
>> Association KAZAR - http://kazar.net/
>> Non profit hosting for anybody in France
>> 
>

From aa at tenet.ac.za  Tue Jan  5 15:38:24 2010
From: aa at tenet.ac.za (Andrew Alston)
Date: Tue, 5 Jan 2010 16:38:24 +0200
Subject: /127 between routers?
In-Reply-To: <alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
Message-ID: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>

We use /127s all over the place on point to point links with no issues
(We went this route after considering what was said in the latest link
Janos posted below)

Haven't really found any drawbacks with this yet

Andrew


-----Original Message-----
From: ipv6-ops-bounces+aa=tenet.ac.za at lists.cluenet.de
[mailto:ipv6-ops-bounces+aa=tenet.ac.za at lists.cluenet.de] On Behalf Of
Mohacsi Janos
Sent: Tuesday, January 05, 2010 4:33 PM
To: Xavier Beaudouin
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: /127 between routers?

Also:
http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt


Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300
6F64 7B00 70EF 9882

On Tue, 5 Jan 2010, Mohacsi Janos wrote:

> Hi,
>
> 	Have a look at RFC 3627:
> http://tools.ietf.org/html/rfc3627
> "Use of /127 Prefix Length Between Routers Considered Harmful"
>
> Janos Mohacsi
> Head of HBONE+ project
> Network Engineer, Deputy Director of Network Planning and Projects 
> NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 
> 6F64 7B00 70EF 9882
>
> On Tue, 5 Jan 2010, Xavier Beaudouin wrote:
>
>> Hi there...
>> 
>> I can't figure if there is any drawback to use a /64 and subnet it 
>> into
>> /127 only for point to point connections between routers.
>> 
>> Seems that OpenBSD doesn't forbid that, but I wanted to know if there

>> is any drawback in this way of connection each routers in such way.
>> 
>> When I was working on 2000 and have 6bone stuff and was pTLA, we 
>> cannot do that, now KAME stack on OpenBSD allow that.
>> 
>> Any good practices in this domain ?
>> 
>> Xavier
>> 
>> --
>> Association KAZAR - http://kazar.net/ Non profit hosting for anybody 
>> in France
>> 
>

From pekkas at netcore.fi  Tue Jan  5 15:47:37 2010
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 5 Jan 2010 16:47:37 +0200 (EET)
Subject: /127 between routers?
In-Reply-To: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
Message-ID: <alpine.LRH.2.00.1001051643580.5818@netcore.fi>

On Tue, 5 Jan 2010, Andrew Alston wrote:
> We use /127s all over the place on point to point links with no issues
> (We went this route after considering what was said in the latest link
> Janos posted below)
>
> Haven't really found any drawbacks with this yet

If you're using SDH or other links where the link type is 
'point-to-point' (in BSD/Linux 'ifconfig' sense, i.e., there is no 
neighbor discovery for link-layer address discovery), /127 is probably 
a good idea considering the tradeoffs.  In practise, nobody has 
implemented subnet-router anycast address mechanism that was a main 
reason for writing RFC3627.

If you only use Ethernet, I don't see much point in /127 specifically, 
other prefix lengths are fine as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From aa at tenet.ac.za  Tue Jan  5 15:54:03 2010
From: aa at tenet.ac.za (Andrew Alston)
Date: Tue, 5 Jan 2010 16:54:03 +0200
Subject: IPv6 and BI-Directional APS
Message-ID: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C39@rouwkoop.ac.za>

Hi All,

 

I was wondering (while I wait for Cisco to come back to me) if anyone
had a solution to the problem of the fact that IPv6 and APS don't seem
to function together correctly on  Cisco 7600s.

 

We have two 7600 series routers on either side of a protected STM-64, we
then run APS on both sides.  

 

This works by allowing us to use the same V4 address on BOTH interfaces
on a single router with APS enabled, so irrespective of which interface
is in working mode and which is in protected the circuit stays working
(The other option would be to use a /29 across the interfaces with one
address per interface in the /29 for a total of 4 addresses and then run
IS-IS between the two routers and bgp neighbor to the loopbacks).

 

However, neither solution works with IPv6 because even with the APS
enabled you cannot have overlapping IPv6 subnets on different interfaces
on the same router.  This means that APS is effectively non-functional
when running IPv6.

 

We also considered running two separate /127s on each "set" of
interfaces, but there is no guarantee that if one side switches to the
protection the other side won't still be on working, in which case this
breaks as well.

 

Any ideas/solutions while I beg Cisco to fix this?

 

Andrew

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100105/a1da5687/attachment.html 

From prox at prolixium.com  Tue Jan  5 16:23:52 2010
From: prox at prolixium.com (Mark Kamichoff)
Date: Tue, 5 Jan 2010 10:23:52 -0500
Subject: /127 between routers?
In-Reply-To: <alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
Message-ID: <20100105152352.GB16923@prolixium.com>

On Tue, Jan 05, 2010 at 03:30:06PM +0100, Mikael Abrahamsson wrote:
> People seem to mostly use /126, /112 or /64 for their p-t-p links.

I've heard rumors that some router vendors (Juniper, others?) are
actually recommending to /avoid/ using /64s on point-to-point links
citing possible performance (ASIC?) issues.

Has anyone heard something similar?

- Mark

-- 
Mark Kamichoff
prox at prolixium.com
http://www.prolixium.com/

From Ken.Mix at clearfly.net  Tue Jan  5 16:28:51 2010
From: Ken.Mix at clearfly.net (Ken Mix)
Date: Tue, 5 Jan 2010 08:28:51 -0700
Subject: /127 between routers?
In-Reply-To: <alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
Message-ID: <10FB8CDC4B3B784AACD5C45FCB395A21A6E8D545@xenon.corp.clearfly.net>

I've also deployed /124s on PTP links to take advantage of the ease of subnetting on a nibble boundary.

Ken


> People seem to mostly use /126, /112 or /64 for their p-t-p links.

From kloch at kl.net  Tue Jan  5 16:46:25 2010
From: kloch at kl.net (Kevin Loch)
Date: Tue, 05 Jan 2010 10:46:25 -0500
Subject: /127 between routers?
In-Reply-To: <alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>	<alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
Message-ID: <4B435ED1.8050408@kl.net>

Mohacsi Janos wrote:
> Also:
> http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt
> 

I use /112 for any link that doesn't have to be /64.
You can't beat the convenience of bit boundaries
on a ':".  It works great for p-p as well as
multi-router and server vlans.

A /112 is only 16,384 times less efficient than a
/126, but is still 281,474,976,710,656 times
more efficient than a /64 :)

- Kevin

From fred at cisco.com  Tue Jan  5 16:46:52 2010
From: fred at cisco.com (Fred Baker)
Date: Tue, 5 Jan 2010 07:46:52 -0800
Subject: /127 between routers?
In-Reply-To: <20100105152352.GB16923@prolixium.com>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
	<20100105152352.GB16923@prolixium.com>
Message-ID: <906BDB0B-6A35-48BF-A1FB-72C1FBAAB4F7@cisco.com>

That would be surprising, as /64s are normally used on Ethernets.

On Jan 5, 2010, at 7:23 AM, Mark Kamichoff wrote:

> On Tue, Jan 05, 2010 at 03:30:06PM +0100, Mikael Abrahamsson wrote:
>> People seem to mostly use /126, /112 or /64 for their p-t-p links.
>
> I've heard rumors that some router vendors (Juniper, others?) are
> actually recommending to /avoid/ using /64s on point-to-point links
> citing possible performance (ASIC?) issues.
>
> Has anyone heard something similar?
>
> - Mark
>
> -- 
> Mark Kamichoff
> prox at prolixium.com
> http://www.prolixium.com/

http://www.ipinc.net/IPv4.GIF


From prox at prolixium.com  Tue Jan  5 17:14:20 2010
From: prox at prolixium.com (Mark Kamichoff)
Date: Tue, 5 Jan 2010 11:14:20 -0500
Subject: /127 between routers?
In-Reply-To: <906BDB0B-6A35-48BF-A1FB-72C1FBAAB4F7@cisco.com>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
	<20100105152352.GB16923@prolixium.com>
	<906BDB0B-6A35-48BF-A1FB-72C1FBAAB4F7@cisco.com>
Message-ID: <20100105161420.GC16923@prolixium.com>

Fred - 

On Tue, Jan 05, 2010 at 07:46:52AM -0800, Fred Baker wrote:
> That would be surprising, as /64s are normally used on Ethernets.

It doesn't make too much sense to me either, which is why I'm curious if
anyone else has heard or has any more information about it.

> http://www.ipinc.net/IPv4.GIF

Nice.

- Mark

-- 
Mark Kamichoff
prox at prolixium.com
http://www.prolixium.com/

From michael at rancid.berkeley.edu  Tue Jan  5 17:19:55 2010
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 05 Jan 2010 08:19:55 -0800
Subject: /127 between routers?
In-Reply-To: <10FB8CDC4B3B784AACD5C45FCB395A21A6E8D545@xenon.corp.clearfly.net>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
	<10FB8CDC4B3B784AACD5C45FCB395A21A6E8D545@xenon.corp.clearfly.net>
Message-ID: <4B4366AB.5050400@rancid.berkeley.edu>

On 1/5/10 7:28 AM, Ken Mix wrote:
> I've also deployed /124s on PTP links to take advantage of the ease of subnetting on a nibble boundary.
>
> Ken
>
>
>> People seem to mostly use /126, /112 or /64 for their p-t-p links.

I have been more conservative and used /96s carved out of a /64 for p2p 
links.  That gives me 32 bits of leeway on either side, allowing me to 
add a couple billion hosts onto my p2p links if I later decide I need 
them or of someone actually does implement subnet anycast.  (Whether 
it's useful or not, someone may decide to implement it or implement 
something that uses it and break your /127s.)  I have used /112s and 
/120s in the past with no problems.  /96 is nice in that it's an easy 
and symmetrical boundary to use.

However, I do agree that there is a lot of waste in using /96s, as it 
affords me "only" 4.3 billion p2ps in a single /64.

Remember, we're going to destroy Internet routing as we know it well 
before we run out of IPv6 addresses.  When we need a new IP after IPv6, 
it won't be because of address exhaustion.

michael

From roger at jorgensen.no  Tue Jan  5 17:34:56 2010
From: roger at jorgensen.no (Roger =?iso-8859-1?Q?J=F8rgensen?=)
Date: Tue, 5 Jan 2010 17:34:56 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
Message-ID: <59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>


On tir, januar 5, 2010 15:38, Andrew Alston wrote:
> We use /127s all over the place on point to point links with no issues
> (We went this route after considering what was said in the latest link
> Janos posted below)
>
> Haven't really found any drawbacks with this yet

Some year back I stopped using /127 when Linux refused to route my
traffic. Had to add a static /128 for part of the /127 to get traffic
flowing again. Later I changed to /126 and the problem disapeared. Wonder
if I even had the same issue on some cisco routers to.

Should be mention that it was all IPv6 in IPv4 tunnels so could be related
to that to...



---


------------------------------
Roger Jorgensen      | - ROJO9-RIPE  - RJ85P-NORID
roger at jorgensen.no           | - The Future is IPv6
-------------------------------------------------------


A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


From a at foo.be  Tue Jan  5 17:34:59 2010
From: a at foo.be (Alexandre Dulaunoy)
Date: Tue, 5 Jan 2010 17:34:59 +0100
Subject: /127 between routers?
In-Reply-To: <4B435ED1.8050408@kl.net>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<4B435ED1.8050408@kl.net>
Message-ID: <1baa801f1001050834h5c173183i144001a01259f60a@mail.gmail.com>

On Tue, Jan 5, 2010 at 4:46 PM, Kevin Loch <kloch at kl.net> wrote:
> Mohacsi Janos wrote:
>>
>> Also:
>> http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt
>>
>
> I use /112 for any link that doesn't have to be /64.
> You can't beat the convenience of bit boundaries
> on a ':". ?It works great for p-p as well as
> multi-router and server vlans.
>
> A /112 is only 16,384 times less efficient than a
> /126, but is still 281,474,976,710,656 times
> more efficient than a /64 :)

On our side, we are using /120 (easy to calculate
and remember) for ptp between routers without any
issues.

ABBA::0000/120
ABBA::0100/120
ABBA::0200/120
ABBA::0300/120
and so on...

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov

From mtinka at globaltransit.net  Tue Jan  5 17:47:48 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 6 Jan 2010 00:47:48 +0800
Subject: /127 between routers?
In-Reply-To: <1baa801f1001050834h5c173183i144001a01259f60a@mail.gmail.com>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<4B435ED1.8050408@kl.net>
	<1baa801f1001050834h5c173183i144001a01259f60a@mail.gmail.com>
Message-ID: <201001060048.00273.mtinka@globaltransit.net>

On Wednesday 06 January 2010 12:34:59 am Alexandre Dulaunoy 
wrote:

> On our side, we are using /120 (easy to calculate
> and remember) for ptp between routers without any
> issues.

Over here, /126's for point-to-points, /112's for LAN's.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100106/43d495c0/attachment.bin 

From mksmith at adhost.com  Tue Jan  5 17:59:58 2010
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 5 Jan 2010 08:59:58 -0800
Subject: /127 between routers?
In-Reply-To: <201001060048.00273.mtinka@globaltransit.net>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><4B435ED1.8050408@kl.net><1baa801f1001050834h5c173183i144001a01259f60a@mail.gmail.com>
	<201001060048.00273.mtinka@globaltransit.net>
Message-ID: <17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>

> -----Original Message-----
> From: ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de
> [mailto:ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de] On
Behalf
> Of Mark Tinka
> Sent: Tuesday, January 05, 2010 8:48 AM
> To: ipv6-ops at lists.cluenet.de
> Cc: Alexandre Dulaunoy
> Subject: Re: /127 between routers?
> 
> * PGP Signed by an unknown key
> 
> On Wednesday 06 January 2010 12:34:59 am Alexandre Dulaunoy
> wrote:
> 
> > On our side, we are using /120 (easy to calculate
> > and remember) for ptp between routers without any
> > issues.
> 
> Over here, /126's for point-to-points, /112's for LAN's.
> 
> Cheers,
> 
> Mark.

We use /64's for interfaces/interface sets/ and route /48's through and
to those interfaces.  Am I in the minority when I look at the fact that
I have 65k /48's and don't really feel the need to subnet beyond a /64?
Operationally, it makes things much simpler as well (in my opinion, of
course).  I get my lower level techs to think in terms of /64's and
/48's rather than those plus any number of more specific subnets.  I
haven't had to do much to tweak our backend systems (all home grown) to
manage these values, etc.

Granted, I do use /128's for loopback addresses.

Regards,

Mike

From sethm at rollernet.us  Tue Jan  5 18:19:57 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 05 Jan 2010 09:19:57 -0800
Subject: /127 between routers?
In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><4B435ED1.8050408@kl.net><1baa801f1001050834h5c173183i144001a01259f60a@mail.gmail.com>	<201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
Message-ID: <4B4374BD.2050006@rollernet.us>

Michael K. Smith - Adhost wrote:
>> -----Original Message-----
>> From: ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de
>> [mailto:ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de] On
> Behalf
>> Of Mark Tinka
>> Sent: Tuesday, January 05, 2010 8:48 AM
>> To: ipv6-ops at lists.cluenet.de
>> Cc: Alexandre Dulaunoy
>> Subject: Re: /127 between routers?
>>
>> * PGP Signed by an unknown key
>>
>> On Wednesday 06 January 2010 12:34:59 am Alexandre Dulaunoy
>> wrote:
>>
>>> On our side, we are using /120 (easy to calculate
>>> and remember) for ptp between routers without any
>>> issues.
>> Over here, /126's for point-to-points, /112's for LAN's.
>>
>> Cheers,
>>
>> Mark.
> 
> We use /64's for interfaces/interface sets/ and route /48's through and
> to those interfaces.  Am I in the minority when I look at the fact that
> I have 65k /48's and don't really feel the need to subnet beyond a /64?
> Operationally, it makes things much simpler as well (in my opinion, of
> course).  I get my lower level techs to think in terms of /64's and
> /48's rather than those plus any number of more specific subnets.  I
> haven't had to do much to tweak our backend systems (all home grown) to
> manage these values, etc.
> 
> Granted, I do use /128's for loopback addresses.
> 

Could be a minority, but you're not alone. I've been using /128's for
loopbacks and /64 for everything else since I went dual-stack.

~Seth

From hardenrm at uiuc.edu  Tue Jan  5 18:25:40 2010
From: hardenrm at uiuc.edu (Ryan Harden)
Date: Tue, 05 Jan 2010 11:25:40 -0600
Subject: /127 between routers?
In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><4B435ED1.8050408@kl.net><1baa801f1001050834h5c173183i144001a01259f60a@mail.gmail.com>	<201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
Message-ID: <4B437614.1050704@uiuc.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/05/2010 10:59 AM, Michael K. Smith - Adhost wrote:
> 
> We use /64's for interfaces/interface sets/ and route /48's through and
> to those interfaces.  Am I in the minority when I look at the fact that
> I have 65k /48's and don't really feel the need to subnet beyond a /64?
> Operationally, it makes things much simpler as well (in my opinion, of
> course).  I get my lower level techs to think in terms of /64's and
> /48's rather than those plus any number of more specific subnets.  I
> haven't had to do much to tweak our backend systems (all home grown) to
> manage these values, etc.
> 

Those of us with a single /48 only have 65k /64s. We're using /126's on
backbone ptp links. Not so much for address conservation but for ease of
management.

1) ACLs are much easier to write. Blocking incoming connections to ptp
links at the border becomes a single /64 ACL, etc.

2) Yes ::1 and ::2 would be pretty easy to remember if we used /64s
everywhere, but we're network engineers. It's just as easy to learn
::1/::2, ::5/::6, ::9/::a, etc.

We're still debating whether or not to use /126 or /64 on
building-backbone links. Right now the compromise is 'use /126 where we
control both sides, /64 where far router is customer/department owned.'

/Ryan

- -- 
Ryan M. Harden, BS, KC9IHX		Office: 217-265-5192
CITES - Network Engineering		Cell:  	217-689-1363
2130 Digital Computer Lab		Fax:    217-244-7089
1304 W. Springfield	 		email:  hardenrm at illinois.edu
Urbana, IL  61801 			

      University of Illinois at Urbana/Champaign - AS38
	   University of Illinois - ICCN - AS40387
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAktDdhIACgkQtuPckBBbXbraVwCdEmQmsQ7ob4MNbjy2gLdt0A4D
JTAAn31v1yMj68XubImgonvy9+RkLmmY
=bxtW
-----END PGP SIGNATURE-----

From dougb at dougbarton.us  Tue Jan  5 18:33:12 2010
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 05 Jan 2010 09:33:12 -0800
Subject: Google filtering ICMPv6 type 2?
In-Reply-To: <sa7zl4s69t6.fsf@benedikt-stockebrand.de>
References: <20100105035039.GB13664@prolixium.com>	<2e8c64261001041955r4f833345w1b62a697229761b9@mail.gmail.com>	<2e8c64261001042004l3f2dfde4ke425b2458fd0c49b@mail.gmail.com>	<20100105041035.GC13664@prolixium.com>	<2e8c64261001042020t65a2b840g5ab06f13c5d90f1d@mail.gmail.com>
	<sa7zl4s69t6.fsf@benedikt-stockebrand.de>
Message-ID: <4B4377D8.50203@dougbarton.us>

Benedikt Stockebrand wrote:
> there was a discussion on a similar approach to this on a (near dead)
> German IPv6 list.  Conclusion: DON'T (sorry for the shouting).
> 
> Path MTU Discovery problems are already quite misleading in nature and
> as such difficult enough to diagnose and even more difficult to
> resolve.  Wantonly clamping down MTUs will only make these tasks
> worse.
> 
> Strategically even more important, once we go down that path we're
> quickly at the point that this approach becomes a "standard procedure"
> and it becomes "your fault" if something breaks "because you
> configured a non-standard MTU" (i.e. one larger than 1280).

I agree strongly with Benedikt here. We're currently dealing with all
sorts of problems in the DNS world due to all sorts of braindead
hardware that hard-coded the assumption that a UDP DNS packet can
never be larger than 512 bytes. The issue of MTUd is one area where I
actually agree that "starting over and doing it right" with IPv6 is
worth the effort.


Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

	Computers are useless. They can only give you answers.
			-- Pablo Picasso


From mtinka at globaltransit.net  Tue Jan  5 18:51:14 2010
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 6 Jan 2010 01:51:14 +0800
Subject: /127 between routers?
In-Reply-To: <4B437614.1050704@uiuc.edu>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<4B437614.1050704@uiuc.edu>
Message-ID: <201001060151.19674.mtinka@globaltransit.net>

On Wednesday 06 January 2010 01:25:40 am Ryan Harden wrote:

> We're still debating whether or not to use /126 or /64 on
> building-backbone links. 

We use /126's for backbone point-to-point links.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100106/9a5e71e7/attachment.bin 

From gert at space.net  Tue Jan  5 19:22:11 2010
From: gert at space.net (Gert Doering)
Date: Tue, 5 Jan 2010 19:22:11 +0100
Subject: IPv6 and BI-Directional APS
In-Reply-To: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C39@rouwkoop.ac.za>
References: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C39@rouwkoop.ac.za>
Message-ID: <20100105182211.GU32226@Space.Net>

Hi,

On Tue, Jan 05, 2010 at 04:54:03PM +0200, Andrew Alston wrote:
> Any ideas/solutions while I beg Cisco to fix this?

What you could do is run the interface without a global IPv6 unicast
address.  OSPFv3 will use the link-local address anyway, while ISIS
uses OSI transport - so neither should require a global unicast address
(please correct me if either assumption is wrong).

For the sake of useful traceroute results, you could use dedicated 
loopbacks and make both interfaces "ipv6 unnumbered lo<X>".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From gert at space.net  Tue Jan  5 20:26:55 2010
From: gert at space.net (Gert Doering)
Date: Tue, 5 Jan 2010 20:26:55 +0100
Subject: /127 between routers?
In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
Message-ID: <20100105192655.GV32226@Space.Net>

Hi,

On Tue, Jan 05, 2010 at 08:59:58AM -0800, Michael K. Smith - Adhost wrote:
> We use /64's for interfaces/interface sets/ and route /48's through and
> to those interfaces.  [..]
> Granted, I do use /128's for loopback addresses.

Same here.  For similar reasons.  Eventually, CGAs and SEND might show
up, and then I might want /64s - and since a single /48 will be sufficient
to number all routers we'll ever have, I stopped doing my IPv4 worries
("oh, this is all so wasteful") here.

I wouldn't want to enter a religious war here, though.  /64s might be
useful one day, or might be not.  /120 and /112 work as well.  So pick
something you're comfortable with.

gert
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Tue Jan  5 22:50:27 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Wed, 6 Jan 2010 08:20:27 +1030
Subject: /127 between routers?
In-Reply-To: <20100105192655.GV32226@Space.Net>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
Message-ID: <20100106082027.72622e52@opy.nosense.org>

On Tue, 5 Jan 2010 20:26:55 +0100
Gert Doering <gert at space.net> wrote:

> Hi,
> 
> On Tue, Jan 05, 2010 at 08:59:58AM -0800, Michael K. Smith - Adhost wrote:
> > We use /64's for interfaces/interface sets/ and route /48's through and
> > to those interfaces.  [..]
> > Granted, I do use /128's for loopback addresses.
> 
> Same here.  For similar reasons.  Eventually, CGAs and SEND might show
> up, and then I might want /64s - and since a single /48 will be sufficient
> to number all routers we'll ever have, I stopped doing my IPv4 worries
> ("oh, this is all so wasteful") here.
> 
> I wouldn't want to enter a religious war here, though.  /64s might be
> useful one day, or might be not.  /120 and /112 work as well.  So pick
> something you're comfortable with.
> 

Why doesn't anybody put a price on managing multiple prefix lengths?
Maybe because they're so used to paying it with IPv4 that they don't
recognise it as a cost?

I'm for 'less is more'. /64s everywhere is less complexity and with
a /48 as an individual/end-site, you get 65536 of them. As an ISP with
a /32 you get 65K /48s, and if you use four of those for your own
internal addressing you'll have 256K /64s - how many ISPs have that
many internal point-to-point or otherwise links and loopbacks?

Why be conservative when the corresponding cost is to to record,
maintain and constantly have to work with and get right, differing
prefix lengths? If it's a /64 or nothing, you can never get it wrong.

Personally I'm considering a slight exception to the above by
using /128s on router etc. loopbacks, however that is for the
convenience of being able to see device IPv6 addresses/IDs by filtering
route table output e.g. "show ipv6 route | inc /128". That's a doubling
of the addressing management cost over just using /64s everywhere,
which is why I'm still debating it a bit.

I think the key realisation I've come to with IPv6 is that you get
enough address space that you don't just have to worrying about
allocating it out to make things work, you can allocate it out to also
make addressing *convenient* to work with, with as simple as possible
usually also being most convenient. Addressing convenience isn't a
property we've had with IPv4 for a long time (e.g. slicing up a Class B
at the 3/4th octets, using the 3rd octet as subnet numbers). With IPv6
we get it back, and we get more of it than we ever had with IPv4.

Regards,
Mark.

From jimb at jsbc.cc  Tue Jan  5 23:41:58 2010
From: jimb at jsbc.cc (Jim Burwell)
Date: Tue, 05 Jan 2010 14:41:58 -0800
Subject: /127 between routers?
In-Reply-To: <59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
Message-ID: <4B43C036.1000609@jsbc.cc>

On 1/5/2010 08:34, Roger J?rgensen wrote:
> On tir, januar 5, 2010 15:38, Andrew Alston wrote:
>   
>> We use /127s all over the place on point to point links with no issues
>> (We went this route after considering what was said in the latest link
>> Janos posted below)
>>
>> Haven't really found any drawbacks with this yet
>>     
> Some year back I stopped using /127 when Linux refused to route my
> traffic. Had to add a static /128 for part of the /127 to get traffic
> flowing again. Later I changed to /126 and the problem disapeared. Wonder
> if I even had the same issue on some cisco routers to.
>
> Should be mention that it was all IPv6 in IPv4 tunnels so could be related
> to that to...
>
>
>   
Makes sense to me.  It would seem to me that /126s were always the
logical equivalents of /30s in the IPv4 world for use on p-t-p links. 
/127s always seemed "wrong"  to me, since it uses the "magic" all-zeros
network identifier address as a host address.  :p 

When I first started learning about IPv6, I wondered it the all-zeros or
all-ones host chunk of an IPv6 address held any special meaning as they
do in IPv4, and quickly figured out that all-ones doesn't, but all-zeros
still does.  A bit annoying in some ways since /127 would make a nice
XYZ::0,1 p-t-p interface address pairs, but oh well.  /126 it is.

Having said that, the existence of that RFC and draft worries me about
using /126s at all, and one wonders if just sticking with /64s as seems
to be extolled as the best practice is the "right thing".  Others have
also made good points about /64 for convenience and consistancy in IPv6
addressing plans.  If it's easy to get say, an entire separate /48 to
use for /64 tunnel end points, then there's not much point in using
/126s, even if the "wastefulness" bugs me a bit.  :)

I've also wondered about the wisdom of perhaps using site-unique
addresses for things like tunnel end points, similar to the way I've
used RFC1918s for the same purpose in the IPv4 world.  Obviously using
non-global-routables wouldn't be good for all circumstances, but for the
typical tunnel or p-t-p link where the interface address might only be
used as a gateway for a local route entry, would it be a bad idea?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5570 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100105/b07f1a25/attachment.bin 

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Wed Jan  6 00:21:09 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Wed, 6 Jan 2010 09:51:09 +1030
Subject: /127 between routers?
In-Reply-To: <4B43C036.1000609@jsbc.cc>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
	<4B43C036.1000609@jsbc.cc>
Message-ID: <20100106095109.2c37b541@opy.nosense.org>

Hi Jim,

On Tue, 05 Jan 2010 14:41:58 -0800
Jim Burwell <jimb at jsbc.cc> wrote:

> On 1/5/2010 08:34, Roger J?rgensen wrote:
> > On tir, januar 5, 2010 15:38, Andrew Alston wrote:
> >   
> >> We use /127s all over the place on point to point links with no issues
> >> (We went this route after considering what was said in the latest link
> >> Janos posted below)
> >>
> >> Haven't really found any drawbacks with this yet
> >>     
> > Some year back I stopped using /127 when Linux refused to route my
> > traffic. Had to add a static /128 for part of the /127 to get traffic
> > flowing again. Later I changed to /126 and the problem disapeared. Wonder
> > if I even had the same issue on some cisco routers to.
> >
> > Should be mention that it was all IPv6 in IPv4 tunnels so could be related
> > to that to...
> >
> >
> >   
> Makes sense to me.  It would seem to me that /126s were always the
> logical equivalents of /30s in the IPv4 world for use on p-t-p links. 
> /127s always seemed "wrong"  to me, since it uses the "magic" all-zeros
> network identifier address as a host address.  :p 
> 
> When I first started learning about IPv6, I wondered it the all-zeros or
> all-ones host chunk of an IPv6 address held any special meaning as they
> do in IPv4, and quickly figured out that all-ones doesn't, but all-zeros
> still does.  A bit annoying in some ways since /127 would make a nice
> XYZ::0,1 p-t-p interface address pairs, but oh well.  /126 it is.
> 
> Having said that, the existence of that RFC and draft worries me about
> using /126s at all, and one wonders if just sticking with /64s as seems
> to be extolled as the best practice is the "right thing".  Others have
> also made good points about /64 for convenience and consistancy in IPv6
> addressing plans.  If it's easy to get say, an entire separate /48 to
> use for /64 tunnel end points, then there's not much point in using
> /126s, even if the "wastefulness" bugs me a bit.  :)
> 

I think Michael Dillon from BT said something like when you live in a
rainforest, you don't worry too much about how much water you use,
which I think is a good analogy. Drop somebody into the rainforest,
who's used to living in the desert, and I think it'd take them a little
while to adjust to how much water they now can use ("use" is not
equal to "waste"). That's the sort of struggle that I think people
who've only used IPv4 will go through. 

> I've also wondered about the wisdom of perhaps using site-unique
> addresses for things like tunnel end points, similar to the way I've
> used RFC1918s for the same purpose in the IPv4 world.  Obviously using
> non-global-routables wouldn't be good for all circumstances, but for the
> typical tunnel or p-t-p link where the interface address might only be
> used as a gateway for a local route entry, would it be a bad idea?
> 

Doing so can break ICMP including PMTUD, traceroute, ping, both in IPv4
and IPv6. The problem is that if the source IP address of the ICMP
message is invalid over a domain it has to travel e.g. RFC1918
addresses on the Internet, things like Reverse Path Forwarding checks
can drop that traffic. If there is any chance of your routers seeing
traffic from the Internet, now or in the future, it's better to use
global i.e. non-private addressing on all of your links.

I think you could get away with it if there was some configuration knob
on the router to originate all ICMP traffic from specific public
address e.g. a /32 (IPv4) or /128 (IPv6) on a loopback interface,
however I haven't come across one yet, although I haven't looked all
that hard.

Regards,
Mark.

From jimb at jsbc.cc  Wed Jan  6 01:27:02 2010
From: jimb at jsbc.cc (Jim Burwell)
Date: Tue, 05 Jan 2010 16:27:02 -0800
Subject: /127 between routers?
In-Reply-To: <20100106095109.2c37b541@opy.nosense.org>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>	<alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>	<4B43C036.1000609@jsbc.cc>
	<20100106095109.2c37b541@opy.nosense.org>
Message-ID: <4B43D8D6.5040605@jsbc.cc>

On 1/5/2010 15:21, Mark Smith wrote:
> Hi Jim,
>
> On Tue, 05 Jan 2010 14:41:58 -0800
> Jim Burwell <jimb at jsbc.cc> wrote:
>
>   
>> On 1/5/2010 08:34, Roger J?rgensen wrote:
>>     
>>> On tir, januar 5, 2010 15:38, Andrew Alston wrote:
>>>   
>>>       
>>>> We use /127s all over the place on point to point links with no issues
>>>> (We went this route after considering what was said in the latest link
>>>> Janos posted below)
>>>>
>>>> Haven't really found any drawbacks with this yet
>>>>     
>>>>         
>>> Some year back I stopped using /127 when Linux refused to route my
>>> traffic. Had to add a static /128 for part of the /127 to get traffic
>>> flowing again. Later I changed to /126 and the problem disapeared. Wonder
>>> if I even had the same issue on some cisco routers to.
>>>
>>> Should be mention that it was all IPv6 in IPv4 tunnels so could be related
>>> to that to...
>>>
>>>
>>>   
>>>       
>> Makes sense to me.  It would seem to me that /126s were always the
>> logical equivalents of /30s in the IPv4 world for use on p-t-p links. 
>> /127s always seemed "wrong"  to me, since it uses the "magic" all-zeros
>> network identifier address as a host address.  :p 
>>
>> When I first started learning about IPv6, I wondered it the all-zeros or
>> all-ones host chunk of an IPv6 address held any special meaning as they
>> do in IPv4, and quickly figured out that all-ones doesn't, but all-zeros
>> still does.  A bit annoying in some ways since /127 would make a nice
>> XYZ::0,1 p-t-p interface address pairs, but oh well.  /126 it is.
>>
>> Having said that, the existence of that RFC and draft worries me about
>> using /126s at all, and one wonders if just sticking with /64s as seems
>> to be extolled as the best practice is the "right thing".  Others have
>> also made good points about /64 for convenience and consistancy in IPv6
>> addressing plans.  If it's easy to get say, an entire separate /48 to
>> use for /64 tunnel end points, then there's not much point in using
>> /126s, even if the "wastefulness" bugs me a bit.  :)
>>
>>     
> I think Michael Dillon from BT said something like when you live in a
> rainforest, you don't worry too much about how much water you use,
> which I think is a good analogy. Drop somebody into the rainforest,
> who's used to living in the desert, and I think it'd take them a little
> while to adjust to how much water they now can use ("use" is not
> equal to "waste"). That's the sort of struggle that I think people
> who've only used IPv4 will go through. 
>
>   
>> I've also wondered about the wisdom of perhaps using site-unique
>> addresses for things like tunnel end points, similar to the way I've
>> used RFC1918s for the same purpose in the IPv4 world.  Obviously using
>> non-global-routables wouldn't be good for all circumstances, but for the
>> typical tunnel or p-t-p link where the interface address might only be
>> used as a gateway for a local route entry, would it be a bad idea?
>>
>>     
> Doing so can break ICMP including PMTUD, traceroute, ping, both in IPv4
> and IPv6. The problem is that if the source IP address of the ICMP
> message is invalid over a domain it has to travel e.g. RFC1918
> addresses on the Internet, things like Reverse Path Forwarding checks
> can drop that traffic. If there is any chance of your routers seeing
> traffic from the Internet, now or in the future, it's better to use
> global i.e. non-private addressing on all of your links.
>
> I think you could get away with it if there was some configuration knob
> on the router to originate all ICMP traffic from specific public
> address e.g. a /32 (IPv4) or /128 (IPv6) on a loopback interface,
> however I haven't come across one yet, although I haven't looked all
> that hard.
>
>   
Yeh I wouldn't use this sort of thing if there was any chance that the
tunnel endpoint addresses would ever go outside of my routing domain. 
The addresses used would be fully routeable inside the enterprise, and I
wouldn't I'd use it anywhere where traffic to or from outside of my
routing domain would pass through it.  So PMTUD, etc, etc would continue
to work inside my enterprise since they'd be routeable.  Basically, I'd
use this, for example, in a leased WAN line scenario between sites which
had their own paths to the internet.  Traffic from the device itself
would never use those interfaces as source.

But it's pretty much moot because of the abundance of available IPv6
addresses.  But as another poster mentioned, old habits die hard when
you just came from the IPv4 "desert" into the IPv6 "rain forest".  :p 

Actually, I've been around long enough to remember when IPv4 addresses
seemed plentiful too, and we didn't do NAT, and had IPv4 publics on all
inside machines and just a normal statefull firewall fronting all that. 
Getting a class B or a bunch of Class C blocks wasn't difficult.  I've
seen IPv6 as a welcome return to those days w/o all the annoyances of
the RFC-1918/NAT world we live in now (such as address overlaps with
partners, aquired/merged companies, etc).  In some ways it'll be like
going back to the late 80s/early 90s.  :p

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5570 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100105/4b0d88a4/attachment.bin 

From ek at google.com  Wed Jan  6 02:22:05 2010
From: ek at google.com (Erik Kline)
Date: Tue, 5 Jan 2010 17:22:05 -0800
Subject: /127 between routers?
In-Reply-To: <4B43D8D6.5040605@jsbc.cc>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
	<4B43C036.1000609@jsbc.cc> <20100106095109.2c37b541@opy.nosense.org>
	<4B43D8D6.5040605@jsbc.cc>
Message-ID: <2e8c64261001051722ja437357h529a184fda81a838@mail.gmail.com>

> Actually, I've been around long enough to remember when IPv4 addresses
> seemed plentiful too, and we didn't do NAT, and had IPv4 publics on all
> inside machines and just a normal statefull firewall fronting all that.
> Getting a class B or a bunch of Class C blocks wasn't difficult. ?I've
> seen IPv6 as a welcome return to those days w/o all the annoyances of
> the RFC-1918/NAT world we live in now (such as address overlaps with
> partners, aquired/merged companies, etc). ?In some ways it'll be like
> going back to the late 80s/early 90s. ?:p

Ditto and amen!

From maz at iij.ad.jp  Wed Jan  6 07:25:02 2010
From: maz at iij.ad.jp (Matsuzaki Yoshinobu)
Date: Wed, 06 Jan 2010 15:25:02 +0900 (JST)
Subject: /127 between routers?
In-Reply-To: <4B43C036.1000609@jsbc.cc>
References: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
	<4B43C036.1000609@jsbc.cc>
Message-ID: <20100106.152502.51274641.maz@iij.ad.jp>

Jim Burwell <jimb at jsbc.cc> wrote
> Makes sense to me.  It would seem to me that /126s were always the
> logical equivalents of /30s in the IPv4 world for use on p-t-p links. 
> /127s always seemed "wrong"  to me, since it uses the "magic" all-zeros
> network identifier address as a host address.  :p 
> 
> When I first started learning about IPv6, I wondered it the all-zeros or
> all-ones host chunk of an IPv6 address held any special meaning as they
> do in IPv4, and quickly figured out that all-ones doesn't, but all-zeros
> still does.  A bit annoying in some ways since /127 would make a nice
> XYZ::0,1 p-t-p interface address pairs, but oh well.  /126 it is.

In case of /126s on p-to-p links, there is an unused all-ones address.
I still worry about it.
 - http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf

A vendor said me the cost of special care for these unused address is
too high - you need double lookup to prevent packet loops.  And they
decided not to perform such double lookup.  So I prefer /127s on
p-to-p links.  It's like an operational insurance to prevent packet
loops.
-----
Matsuzaki Yoshinobu <maz at iij.ad.jp>
 - IIJ/AS2497  INOC-DBA: 2497*629

From jimb at jsbc.cc  Wed Jan  6 09:41:26 2010
From: jimb at jsbc.cc (Jim Burwell)
Date: Wed, 06 Jan 2010 00:41:26 -0800
Subject: /127 between routers?
In-Reply-To: <20100106.152502.51274641.maz@iij.ad.jp>
References: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>	<4B43C036.1000609@jsbc.cc>
	<20100106.152502.51274641.maz@iij.ad.jp>
Message-ID: <4B444CB6.8080905@jsbc.cc>

On 1/5/2010 22:25, Matsuzaki Yoshinobu wrote:
> Jim Burwell <jimb at jsbc.cc> wrote
>   
>> Makes sense to me.  It would seem to me that /126s were always the
>> logical equivalents of /30s in the IPv4 world for use on p-t-p links. 
>> /127s always seemed "wrong"  to me, since it uses the "magic" all-zeros
>> network identifier address as a host address.  :p 
>>
>> When I first started learning about IPv6, I wondered it the all-zeros or
>> all-ones host chunk of an IPv6 address held any special meaning as they
>> do in IPv4, and quickly figured out that all-ones doesn't, but all-zeros
>> still does.  A bit annoying in some ways since /127 would make a nice
>> XYZ::0,1 p-t-p interface address pairs, but oh well.  /126 it is.
>>     
> In case of /126s on p-to-p links, there is an unused all-ones address.
> I still worry about it.
>  - http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf
>
> A vendor said me the cost of special care for these unused address is
> too high - you need double lookup to prevent packet loops.  And they
> decided not to perform such double lookup.  So I prefer /127s on
> p-to-p links.  It's like an operational insurance to prevent packet
> loops.
> -----
> Matsuzaki Yoshinobu <maz at iij.ad.jp>
>  - IIJ/AS2497  INOC-DBA: 2497*629
>   
Interesting.  I'd hope most vendors would implement the RFC4443 special
case. 

Perhaps another solution in the case of a /126 would be to simply add
the all-ones address to one (or both) side, that way they simply respond
to that address as appropriate, and eliminate the forwarding loop
problem.  That is:

RT1 (2001:db8::1/126, 2001:db8::3/126) <--- ptp ---> (2001:db8::2/126) RT2

That way, the unused address doesn't result in the forwarding loop, and
no need for ACLs or anything like that.

Obviously this wouldn't work for /64s, so you'd use ACLs for that, or
the vendor would have to implement RFC4443, or perhaps some convention
could be used where all but the first two IPv6 host addresses on a p-t-p
link are dropped automatically (or alternatively accepted as if that
interface were the one addressed)?

Or maybe I'm too tired to be thinking about this right now.  :p


From rogerj at jorgensen.no  Wed Jan  6 09:57:43 2010
From: rogerj at jorgensen.no (Roger Jorgensen)
Date: Wed, 6 Jan 2010 09:57:43 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <4B43C036.1000609@jsbc.cc>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><alpine.BSF.2.00.1001051528150.40308@mignon.ki.iif.hu>
	<alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
	<4B43C036.1000609@jsbc.cc>
Message-ID: <alpine.LRH.2.00.1001060955160.3576@quadrunner.jorgensen.no>

On Tue, 5 Jan 2010, Jim Burwell wrote:
<snip
> On 1/5/2010 08:34, Roger J?rgensen wrote:
<snip>
> > Some year back I stopped using /127 when Linux refused to route my
> > traffic. Had to add a static /128 for part of the /127 to get traffic
> > flowing again. Later I changed to /126 and the problem disapeared. Wonder
> > if I even had the same issue on some cisco routers to.
> >
> > Should be mention that it was all IPv6 in IPv4 tunnels so could be related
> > to that to...
<snip>
> 
> Having said that, the existence of that RFC and draft worries me about
> using /126s at all, and one wonders if just sticking with /64s as seems
> to be extolled as the best practice is the "right thing".  Others have
> also made good points about /64 for convenience and consistancy in IPv6
> addressing plans.  If it's easy to get say, an entire separate /48 to
> use for /64 tunnel end points, then there's not much point in using
> /126s, even if the "wastefulness" bugs me a bit.  :)

If you ask me... anything else than 127 and 126 is a good thing.
/128, /112 or /64 is really all the same as long as the use is thought 
through.



-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
roger at jorgensen.no           | - IPv6 is The Key!
-------------------------------------------------------

From madams at netcologne.de  Wed Jan  6 10:17:19 2010
From: madams at netcologne.de (Michael Adams)
Date: Wed, 06 Jan 2010 10:17:19 +0100
Subject: /127 between routers?
In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>,
	<201001060048.00273.mtinka@globaltransit.net>,
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
Message-ID: <4B44551F.11432.ABC4F62@madams.netcologne.de>

Michael K. Smith - Adhost,  5 Jan 2010 8:59:

> We use /64's for interfaces/interface sets/ and route /48's through and
> to those interfaces.  Am I in the minority when I look at the fact that
> I have 65k /48's and don't really feel the need to subnet beyond a /64?
> Operationally, it makes things much simpler as well (in my opinion, of
> course).  I get my lower level techs to think in terms of /64's and

I don't know if we are in the minority but you're not alone :)
We are using /64 on all interfaces (ethernet, loopback) just because
the host id is defined as 64 bits.

>From time to time I see discussions if anything other than /64 is harmful
or not. But I can't remember any discussion if /64 is harmful. For me this
is a reason to keep on using /64.

If anyone sees problems with /64 except possible loops on p2p interfaces
(sdh world,...) please let me know.

regards,
Michael

-- 
Michael Adams                             Tel: +49 221 2222 657
Network Engineering & Design              Fax: +49 221 2222 7657

NetCologne                                Gesch?ftsf?hrer
Gesellschaft f?r Telekommunikation mbH    Werner Hanf
Am Coloneum 9                             Dipl.-Ing. Karl-Heinz Zankel
50829 K?ln                                HRB 25580, Amtsgericht K?ln



From gert at space.net  Wed Jan  6 11:01:53 2010
From: gert at space.net (Gert Doering)
Date: Wed, 6 Jan 2010 11:01:53 +0100
Subject: /127 between routers?
In-Reply-To: <4B43C036.1000609@jsbc.cc>
References: <alpine.BSF.2.00.1001051532560.40308@mignon.ki.iif.hu>
	<E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
	<4B43C036.1000609@jsbc.cc>
Message-ID: <20100106100153.GC32226@Space.Net>

Hi,

On Tue, Jan 05, 2010 at 02:41:58PM -0800, Jim Burwell wrote:
> I've also wondered about the wisdom of perhaps using site-unique
> addresses for things like tunnel end points, similar to the way I've
> used RFC1918s for the same purpose in the IPv4 world.  

Don't.  For the same reason you are not supposed to do so in the IPv4
world - it will leak packets (ICMP on traceroute or PMTUd) to the world
that come from source addresses that are not supposed to be seen 
globally.

You can run the tunnels without explicit addresses, just using link-locals
(and the router will then pick another IPv6 address for sending out
ICMPs, potentially guided by configuring "ipv6 unnumbered loopback<n>").

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From pekkas at netcore.fi  Thu Jan  7 07:37:44 2010
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 7 Jan 2010 08:37:44 +0200 (EET)
Subject: /127 between routers?
In-Reply-To: <20100106.152502.51274641.maz@iij.ad.jp>
References: <E65B3ED7E6FCBA48BC3E2FA89972921601E15C38@rouwkoop.ac.za>
	<59672.193.71.255.83.1262709296.squirrel@mail.e-konsult.no>
	<4B43C036.1000609@jsbc.cc> <20100106.152502.51274641.maz@iij.ad.jp>
Message-ID: <alpine.LRH.2.00.1001070834330.29958@netcore.fi>

On Wed, 6 Jan 2010, Matsuzaki Yoshinobu wrote:
> A vendor said me the cost of special care for these unused address is
> too high - you need double lookup to prevent packet loops.  And they
> decided not to perform such double lookup.  So I prefer /127s on
> p-to-p links.  It's like an operational insurance to prevent packet
> loops.

There are no packet loops on interfaces that use address resolution, 
e.g. Ethernet.  This is a problem with SDH/SONET and similar p2p 
interfaces, however.  It would be clearer to everyone if the 
proponents of /127 would remember to say that when crying wolf (packet 
loops).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From Sam.Wilson at ed.ac.uk  Thu Jan  7 12:25:23 2010
From: Sam.Wilson at ed.ac.uk (Sam Wilson)
Date: Thu, 7 Jan 2010 11:25:23 +0000
Subject: /127 between routers?
In-Reply-To: <20100106082027.72622e52@opy.nosense.org>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
Message-ID: <2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>


On 5 Jan 2010, at 21:50, Mark Smith wrote:

> On Tue, 5 Jan 2010 20:26:55 +0100
> Gert Doering <gert at space.net> wrote:
>
>> Hi,
>>
>> On Tue, Jan 05, 2010 at 08:59:58AM -0800, Michael K. Smith -  
>> Adhost wrote:
>>> We use /64's for interfaces/interface sets/ and route /48's  
>>> through and
>>> to those interfaces.  [..]
>>> Granted, I do use /128's for loopback addresses.
>>
>> Same here.  For similar reasons.  Eventually, CGAs and SEND might  
>> show
>> up, and then I might want /64s - and since a single /48 will be  
>> sufficient
>> to number all routers we'll ever have, I stopped doing my IPv4  
>> worries
>> ("oh, this is all so wasteful") here.
>>
>> I wouldn't want to enter a religious war here, though.  /64s might be
>> useful one day, or might be not.  /120 and /112 work as well.  So  
>> pick
>> something you're comfortable with.
>>
>
> Why doesn't anybody put a price on managing multiple prefix lengths?
> Maybe because they're so used to paying it with IPv4 that they don't
> recognise it as a cost?
>
> I'm for 'less is more'. /64s everywhere is less complexity and with
> a /48 as an individual/end-site, you get 65536 of them. As an ISP with
> a /32 you get 65K /48s, and if you use four of those for your own
> internal addressing you'll have 256K /64s - how many ISPs have that
> many internal point-to-point or otherwise links and loopbacks?
>
> Why be conservative when the corresponding cost is to to record,
> maintain and constantly have to work with and get right, differing
> prefix lengths? If it's a /64 or nothing, you can never get it wrong.

Let me delurk and offer the following:

- IPv6 allows arbitrary prefix lengths (RFC 4291 2.5 para 1)
- IPv6 allows maximum 64-bit subnet prefix lengths in the currently  
allocated global unicast address space (RFC 4291 2.5.1 para 3)
- current IPv6 implementations clearly do not enforce this restriction

The second bullet point above seems to reflect the 8+8 architecture  
proposed by Mike O'Dell [1] or the network+host architecture of  
Novell IPX and the like.  Part of O'Dell's argument was that routing  
kit should be optimised for making routing decisions only on the  
upper 64 bits of an address.  What worries me in Mark's proposal (if  
it's that not inflating the strength of what he's saying) is that we  
might end up with 8+8 by stealth - CPE which only recognises 64-bit  
prefixes, big-iron routers that route 64-bit prefixes in the fast  
path and relegate anything longer to slower processing.  It feels as  
though someone should be deciding either that subnet prefixes should  
never be longer than 64 bits or championing the right for prefixes to  
be any old length you want.

> Personally I'm considering a slight exception to the above by
> using /128s on router etc. loopbacks, however that is for the
> convenience of being able to see device IPv6 addresses/IDs by  
> filtering
> route table output e.g. "show ipv6 route | inc /128". That's a  
> doubling
> of the addressing management cost over just using /64s everywhere,
> which is why I'm still debating it a bit

The same argument applies to management systems - what happens when  
the only systems available assume that the longest subnet prefixes  
is /64 because that's what's currently in use (RFC 4291 2.5 vs  
2.5.1)?  What about staff training?

> I think the key realisation I've come to with IPv6 is that you get
> enough address space that you don't just have to worrying about
> allocating it out to make things work, you can allocate it out to also
> make addressing *convenient* to work with, with as simple as possible
> usually also being most convenient. Addressing convenience isn't a
> property we've had with IPv4 for a long time (e.g. slicing up a  
> Class B
> at the 3/4th octets, using the 3rd octet as subnet numbers). With IPv6
> we get it back, and we get more of it than we ever had with IPv4.

I (FWIW) think the key realisation with IPv6 is that we have too many  
bits available and don't really know what to do with them.  :-)


Sam Wilson
Network Team, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK




-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From Sam.Wilson at ed.ac.uk  Thu Jan  7 12:31:29 2010
From: Sam.Wilson at ed.ac.uk (Sam Wilson)
Date: Thu, 7 Jan 2010 11:31:29 +0000
Subject: /127 between routers?
In-Reply-To: <20100106082027.72622e52@opy.nosense.org>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
Message-ID: <E06B705F-4662-4A46-8753-1500DD7AAC2B@ed.ac.uk>

I wrote "the 8+8 architecture proposed by Mike O'Dell [1]" and then  
forgot the footnote.  It's below.

[1] <http://www.potaroo.net/ietf/old-ids/draft-odell-8+8-00.txt>

Sam Wilson
Network Team, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From michael.dillon at bt.com  Thu Jan  7 14:31:04 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 7 Jan 2010 13:31:04 -0000
Subject: /127 between routers?
In-Reply-To: <2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
Message-ID: <28E139F46D45AF49A31950F88C49745804BA5DD7@E03MVZ2-UKDY.domain1.systemhost.net>

> What worries me in Mark's proposal (if it's that not inflating the
strength of what he's saying) is that we might end up with 8+8 by
stealth - CPE which only recognises 64-bit prefixes, big-iron routers
that route 64-bit prefixes in the fast path and relegate anything longer
to slower processing. 

Sounds good to me. If hardware designers can provide a way to speed up
some traffic, then that is a good thing.

>  It feels as though someone should be deciding either that subnet
prefixes should never be longer than 64 bits or championing the right
for prefixes to be any old length you want.

Championing? This is not politics, this is technology. If the technology
allows for divide and conquer to be applied to separating traffic into a
fast path and a slow path, then it will happen.

The same argument applies to management systems - what happens when the
only systems available assume that the longest subnet prefixes is /64
because that's what's currently in use (RFC 4291 2.5 vs 2.5.1)?  What
about staff training?

Then people will renumber their networks to use /64 prefixes on all
their p-t-p links. Staff training is easy, or maybe we should say that
any competent operator already has ongoing staff training in place so
whatever comes along, it can be handled.

> I think the key realisation I've come to with IPv6 is that you get 
> enough address space that you don't just have to worrying about 
> allocating it out to make things work, you can allocate it out to also

> make addressing *convenient* to work with, with as simple as possible 
> usually also being most convenient. 

Yes, yes and yes again. Keep it simple and don't worry about waste
because
to date, we haven't really got a definition of "waste" for IPv6. The
only 
place where you have to worry is that an operator who gives customer
sites
a prefix shorter than /48 must make sure that they can justify it when
their
initial /32 (or whatever) is used up.

I (FWIW) think the key realisation with IPv6 is that we have too many
bits available and don't really know what to do with them.  :-)

That's why only 1/8th of the IPv6 address space is allotted for global
unicast.

--Michael Dillon

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Thu Jan  7 15:01:07 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Fri, 8 Jan 2010 00:31:07 +1030
Subject: /127 between routers?
In-Reply-To: <2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
Message-ID: <20100108003107.678d9fbb@opy.nosense.org>

On Thu, 7 Jan 2010 11:25:23 +0000
Sam Wilson <Sam.Wilson at ed.ac.uk> wrote:

> 
> On 5 Jan 2010, at 21:50, Mark Smith wrote:
> 
> > On Tue, 5 Jan 2010 20:26:55 +0100
> > Gert Doering <gert at space.net> wrote:
> >
> >> Hi,
> >>
> >> On Tue, Jan 05, 2010 at 08:59:58AM -0800, Michael K. Smith -  
> >> Adhost wrote:
> >>> We use /64's for interfaces/interface sets/ and route /48's  
> >>> through and
> >>> to those interfaces.  [..]
> >>> Granted, I do use /128's for loopback addresses.
> >>
> >> Same here.  For similar reasons.  Eventually, CGAs and SEND might  
> >> show
> >> up, and then I might want /64s - and since a single /48 will be  
> >> sufficient
> >> to number all routers we'll ever have, I stopped doing my IPv4  
> >> worries
> >> ("oh, this is all so wasteful") here.
> >>
> >> I wouldn't want to enter a religious war here, though.  /64s might be
> >> useful one day, or might be not.  /120 and /112 work as well.  So  
> >> pick
> >> something you're comfortable with.
> >>
> >
> > Why doesn't anybody put a price on managing multiple prefix lengths?
> > Maybe because they're so used to paying it with IPv4 that they don't
> > recognise it as a cost?
> >
> > I'm for 'less is more'. /64s everywhere is less complexity and with
> > a /48 as an individual/end-site, you get 65536 of them. As an ISP with
> > a /32 you get 65K /48s, and if you use four of those for your own
> > internal addressing you'll have 256K /64s - how many ISPs have that
> > many internal point-to-point or otherwise links and loopbacks?
> >
> > Why be conservative when the corresponding cost is to to record,
> > maintain and constantly have to work with and get right, differing
> > prefix lengths? If it's a /64 or nothing, you can never get it wrong.
> 
> Let me delurk and offer the following:
> 
> - IPv6 allows arbitrary prefix lengths (RFC 4291 2.5 para 1)

History has shown that creating hard boundaries between the network and
node portion (i.e. Classful addressing) may reduce forwarding
system flexibility and require mass software/hardware upgrades. I think
the lesson learned from the Classful to CIDR transition in the mid 90s
was to avoid any structure in addressing, and make forwarding
decisions using a separate prefix length value. Fortunately it was
feasible at that time to perform software upgrades (did IPv4 hardware
forwarding exist?) to the routers in the Internet to change the way
they performed address lookups in route tables.

> - IPv6 allows maximum 64-bit subnet prefix lengths in the currently  
> allocated global unicast address space (RFC 4291 2.5.1 para 3)

History shows that humans deal best with simplicity. To my
knowledge, all major protocols (IPv4 (RFC760, "Addressing", or
Internet Engineering Note 5 (in the ien subdirectory of an RFC archive),
4.3.2), IPX, Appletalk, DECNet), except CLNS (from what I understand, a
copy of IPv4 at the time with some "necessary improvements"), have
initially been designed with a simple fixed length node address, and a
fixed length network address.

> - current IPv6 implementations clearly do not enforce this restriction
> 

If you combine the desirable properties of both forwarding based on an
arbitrary number of significant bits, and a simple fixed length node
address, I think you end up with IPv6 as we have it today. The reason
why IPv6 implementations don't strictly enforce the /64 boundary at
the forwarding level is because it is a soft boundary - this will
avoid wide scale and probably now impossible software upgrades or
hardware replacements to change the forwarding method used for IPv6.
I'm of the opinion that one of the reasons that there is only a single,
fixed node address (soft) boundary is that operational simplicity has
value, and if you can afford it, you should have it. Those of us who've
worked with protocols other than IPv4, such as Novell's IPX or
Appletalk, will have experienced that simplicity. Since that /64
boundary was decided, other value has come out of that single and large
node portion e.g. SEND. 

> The second bullet point above seems to reflect the 8+8 architecture  
> proposed by Mike O'Dell [1] or the network+host architecture of  
> Novell IPX and the like.  Part of O'Dell's argument was that routing  
> kit should be optimised for making routing decisions only on the  
> upper 64 bits of an address.  What worries me in Mark's proposal (if  
> it's that not inflating the strength of what he's saying) is that we  
> might end up with 8+8 by stealth - CPE which only recognises 64-bit  
> prefixes, big-iron routers that route 64-bit prefixes in the fast  
> path and relegate anything longer to slower processing.  It feels as  
> though someone should be deciding either that subnet prefixes should  
> never be longer than 64 bits or championing the right for prefixes to  
> be any old length you want.
> 

Somebody has decided that the subnet prefix length should never be
longer than 64 bits - it's stated in RFC4291, "IPv6 Addressing
Architecture"

"  For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

> > Personally I'm considering a slight exception to the above by
> > using /128s on router etc. loopbacks, however that is for the
> > convenience of being able to see device IPv6 addresses/IDs by  
> > filtering
> > route table output e.g. "show ipv6 route | inc /128". That's a  
> > doubling
> > of the addressing management cost over just using /64s everywhere,
> > which is why I'm still debating it a bit
> 
> The same argument applies to management systems - what happens when  
> the only systems available assume that the longest subnet prefixes  
> is /64 because that's what's currently in use (RFC 4291 2.5 vs  
> 2.5.1)?  What about staff training?
> 

I find that argument a bit hard to swallow. Surely you're not saying
that the only reason why we can't have the simplicity and other
benefits of a single fixed length node address is so that network
management systems don't build in a maximum prefix length assumption,
even though the current RFCs say that this is an assumption that can be
made?

The only reason I'm wavering on using /128s on OAM loopbacks is
because there'll only ever be one "node" on that virtual network, and I
don't think I'd ever need any of the features that can take advantage
of 64 bit fixed length node addresses. But probably I shouldn't make
that assumption, as it's less future proof than always using /64s. If I
had 10 000 routers, and used /64s on each of their OAM loopbacks, with
20 000 or so links between them, I've still got 30 000 /64s left out of
a /48. Why am I bothering to be so unnecessarily conservative? (and
I've probably just made my mind up on that one - there's more
operational safety in following the IPv6 addressing models described in
the RFCs. Future RFCs, which may add features I'll find useful, will
be assuming those previously specified addressing models.)

> > I think the key realisation I've come to with IPv6 is that you get
> > enough address space that you don't just have to worrying about
> > allocating it out to make things work, you can allocate it out to also
> > make addressing *convenient* to work with, with as simple as possible
> > usually also being most convenient. Addressing convenience isn't a
> > property we've had with IPv4 for a long time (e.g. slicing up a  
> > Class B
> > at the 3/4th octets, using the 3rd octet as subnet numbers). With IPv6
> > we get it back, and we get more of it than we ever had with IPv4.
> 
> I (FWIW) think the key realisation with IPv6 is that we have too many  
> bits available and don't really know what to do with them.  :-)
> 

I think we'll use them for operational simplicity and convenience, and
fancy things like SEND and CGA, similar to how we've used the extra 32
or so operationally unnecessary bits in Ethernet addresses for the last
20 or so years.

Regards,
Mark.

From Sam.Wilson at ed.ac.uk  Thu Jan  7 17:01:54 2010
From: Sam.Wilson at ed.ac.uk (Sam Wilson)
Date: Thu, 7 Jan 2010 16:01:54 +0000
Subject: /127 between routers?
In-Reply-To: <28E139F46D45AF49A31950F88C49745804BA5DD7@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745804BA5DD7@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <704DE541-9F58-4A6B-81D7-B6821B9522FD@ed.ac.uk>


On 7 Jan 2010, at 13:31, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

>> What worries me in Mark's proposal (if it's that not inflating the
>> strength of what he's saying) is that we might end up with 8+8 by
>> stealth - CPE which only recognises 64-bit prefixes, big-iron routers
>> that route 64-bit prefixes in the fast path and relegate anything  
>> longer
>> to slower processing.
>
>
> Sounds good to me. If hardware designers can provide a way to speed up
> some traffic, then that is a good thing.

And if some mfr of inexpensive CPE assumes that no prefix can be  
longer than /64 and then an ISP starts handing out longer prefixes  
with [whatever mechanism] PD (I'm not saying that's likely, but it's  
technically possible)?  Remember "DNS packets aren't longer than 512  
bytes"?


>>  It feels as though someone should be deciding either that subnet
>> prefixes should never be longer than 64 bits or championing the right
>> for prefixes to be any old length you want.
>
>
> Championing? This is not politics, this is technology. If the  
> technology
> allows for divide and conquer to be applied to separating traffic  
> into a
> fast path and a slow path, then it will happen.

I think you're missing my point.  At present the (proposed) standard  
says you can have any length prefix you want except in the 1/8 of the  
address space that is currently available, where the max is /64.   
This entire thread is about non-/64 addresses in that address space.   
Doesn't that make you uneasy?

>> The same argument applies to management systems - what happens  
>> when the
>> only systems available assume that the longest subnet prefixes is /64
>> because that's what's currently in use (RFC 4291 2.5 vs 2.5.1)?  What
>> about staff training?
>
>
> Then people will renumber their networks to use /64 prefixes on all
> their p-t-p links. Staff training is easy, or maybe we should say that
> any competent operator already has ongoing staff training in place so
> whatever comes along, it can be handled.

Except that the (proposed) standard says that for other blocks of  
address space there is no presumption of maximum prefix length.   
People will forget that if the culture says /64 everywhere.


Sam Wilson
Network Team, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From benny+usenet at amorsen.dk  Thu Jan  7 18:26:08 2010
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 07 Jan 2010 18:26:08 +0100
Subject: /127 between routers?
In-Reply-To: <20100108003107.678d9fbb@opy.nosense.org> (Mark Smith's message
	of "Fri, 8 Jan 2010 00:31:07 +1030")
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<20100108003107.678d9fbb@opy.nosense.org>
Message-ID: <m3r5q13jyn.fsf@ursa.amorsen.dk>

Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
writes:

> History has shown that creating hard boundaries between the network and
> node portion (i.e. Classful addressing) may reduce forwarding
> system flexibility and require mass software/hardware upgrades.

You can't apply a lesson learned when addresses are scarce to a scenario
where addresses are plentiful. I bet we would hear the exact same
concerns if IPv6 addresses were 256-bit.


/Benny


From gbonser at seven.com  Thu Jan  7 19:39:20 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 7 Jan 2010 10:39:20 -0800
Subject: /127 between routers?
In-Reply-To: <m3r5q13jyn.fsf@ursa.amorsen.dk>
References: <201001060048.00273.mtinka@globaltransit.net><17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan><20100105192655.GV32226@Space.Net><20100106082027.72622e52@opy.nosense.org><2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk><20100108003107.678d9fbb@opy.nosense.org>
	<m3r5q13jyn.fsf@ursa.amorsen.dk>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F718E@RWC-EX1.corp.seven.com>


> > History has shown that creating hard boundaries between the network
> and
> > node portion (i.e. Classful addressing) may reduce forwarding
> > system flexibility and require mass software/hardware upgrades.
> 
> You can't apply a lesson learned when addresses are scarce to a
> scenario
> where addresses are plentiful. I bet we would hear the exact same
> concerns if IPv6 addresses were 256-bit.
> 
> 
> /Benny

I can imagine all sorts of things happening after the widespread
deployment of v6.  For example, let's say you currently have some kind
of application that keeps session state on a server that is in a
cluster.  So when a request arrives, you use some sort of session ID to
locate the server with the state information.  But let's say with v6 you
now simply program an ip address that has the value of the session ID.
To find the server with the state, you simply connect to the IP address
represented by or that is derived as some function of the session ID.

We might see servers with thousands of IP addresses configured where
those IP addresses are basically session cookies.  This is going to put
some interesting pressure on kernel developers. So you have a subnet
where the addresses are basically nothing more than 64-bit GUIDs
representing client connections.  Want to find where the client state
is?  No problem, connect to the GUID as the IP address or redirect the
connection there.  No more cluster software needed.




From alan.batie at peakinternet.com  Thu Jan  7 21:28:55 2010
From: alan.batie at peakinternet.com (Alan Batie)
Date: Thu, 07 Jan 2010 12:28:55 -0800
Subject: /127 between routers?
In-Reply-To: <28E139F46D45AF49A31950F88C49745804BA5DD7@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745804BA5DD7@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4B464407.6080209@peakinternet.com>

On 1/7/10 5:31 AM, michael.dillon at bt.com wrote:

> Yes, yes and yes again. Keep it simple and don't worry about waste because
> to date, we haven't really got a definition of "waste" for IPv6.

I would suggest that if we don't want to suddenly discover that
definition, we don't completely abandon the notion either.  We have the
breathing room to make things convenient, but it's not infinite, and
it's not hard to chew up vast amounts of space "organizing".  Long
prefixes for infrastructure connections make a lot of sense to me...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5280 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100107/0e24bba1/attachment.bin 

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Fri Jan  8 01:34:43 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Fri, 8 Jan 2010 11:04:43 +1030
Subject: /127 between routers?
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F718E@RWC-EX1.corp.seven.com>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<20100108003107.678d9fbb@opy.nosense.org>
	<m3r5q13jyn.fsf@ursa.amorsen.dk>
	<5A6D953473350C4B9995546AFE9939EE081F718E@RWC-EX1.corp.seven.com>
Message-ID: <20100108110443.48e3a46a@opy.nosense.org>

On Thu, 7 Jan 2010 10:39:20 -0800
"George Bonser" <gbonser at seven.com> wrote:

> 
> > > History has shown that creating hard boundaries between the network
> > and
> > > node portion (i.e. Classful addressing) may reduce forwarding
> > > system flexibility and require mass software/hardware upgrades.
> > 
> > You can't apply a lesson learned when addresses are scarce to a
> > scenario
> > where addresses are plentiful. I bet we would hear the exact same
> > concerns if IPv6 addresses were 256-bit.
> > 
> > 
> > /Benny
> 
> I can imagine all sorts of things happening after the widespread
> deployment of v6.  For example, let's say you currently have some kind
> of application that keeps session state on a server that is in a
> cluster.  So when a request arrives, you use some sort of session ID to
> locate the server with the state information.  But let's say with v6 you
> now simply program an ip address that has the value of the session ID.
> To find the server with the state, you simply connect to the IP address
> represented by or that is derived as some function of the session ID.
> 
> We might see servers with thousands of IP addresses configured where
> those IP addresses are basically session cookies.  This is going to put
> some interesting pressure on kernel developers. So you have a subnet
> where the addresses are basically nothing more than 64-bit GUIDs
> representing client connections.  Want to find where the client state
> is?  No problem, connect to the GUID as the IP address or redirect the
> connection there.  No more cluster software needed.
> 
> 
> 

Sounds like what is in this paper -

"Transient addressing for related processes: Improved firewalling by
using IPv6 and multiple addresses per host." - Peter M. Gleitz and
Steven M. Bellovin

http://www.cs.columbia.edu/~smb/papers/tarp.pdf


From me at benedikt-stockebrand.de  Fri Jan  8 15:25:42 2010
From: me at benedikt-stockebrand.de (Benedikt Stockebrand)
Date: Fri, 08 Jan 2010 14:25:42 +0000
Subject: /127 between routers?
In-Reply-To: <2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk> (Sam Wilson's
	message of "Thu, 7 Jan 2010 11:25:23 +0000")
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
Message-ID: <sa77hrsllll.fsf@benedikt-stockebrand.de>

Hello list,

just trying to catch up with the list, so I'll pick up a couple
subthreads simultaneously.


Sam Wilson <Sam.Wilson at ed.ac.uk> writes:

> - IPv6 allows arbitrary prefix lengths (RFC 4291 2.5 para 1)
> - IPv6 allows maximum 64-bit subnet prefix lengths in the currently
> allocated global unicast address space (RFC 4291 2.5.1 para 3)
> - current IPv6 implementations clearly do not enforce this restriction

That's not quite true.  RFC 4291, par's 2.5.4, 2.5.6, 2.5.7 and RFC
4193 par 3.1 also state that global, link-local, site-local and
unique-local unicast addresses have a fixed /64 subnet prefix.

Only unicast addresses from the ::/3 range (loopback, compatible and
mapped addresses) are currently defined to have different prefixes,
for more or less obvious reasons.

In summary, this means that IP stack implementations can't rely on a
fixed /64 boundary because future standards may come up with new
address ranges with semantics that require a non-/64 subnet prefix.
So stack implementations should be coded in a way that supports
non-/64 prefixes to avoid major rewrites and problems in the future.

But anything using addresses from the existing ranges may well assume
a /64 prefix in full compliance with the standards.


Pekka Savola <pekkas at netcore.fi> writes:

> If you're using SDH or other links where the link type is
> 'point-to-point' (in BSD/Linux 'ifconfig' sense, i.e., there is no
> neighbor discovery for link-layer address discovery), /127 is
> probably a good idea considering the tradeoffs.  In practise, nobody
> has implemented subnet-router anycast address mechanism that was a
> main reason for writing RFC3627.

Now I currently don't have a chance to test this (I'm revamping my
testbed right now), but unless I am completely mistaken then you can
configure point-to-point links between *arbitrary* addresses and don't
need any subnet prefix at all.

The RFCs I have seen so far largely ignore the existence of ptp links,
so in the long run this may not be exactly the least troublesome
approach.  (Pointers to RFCs I may have missed always and explicitly
welcome!)

If you really want to "save" addresses, you can do away entirely with
subnets on ptp links.  And yes, if I remember correctly this even
works with at least RIP and OSPF (I don't do EIGRP).


Mark Smith writes:

> Why doesn't anybody put a price on managing multiple prefix lengths?
> Maybe because they're so used to paying it with IPv4 that they don't
> recognise it as a cost?

This is the very key question to ask.

The answer, in numbers, depends on your particular environment, but
these are some items I'd enter into the calculation:

Cost of non-/64 subnet prefixes:

- Additional configuration effort.  (Preferably if you have to talk an
  amateur end user through it on the phone.)

- Additional troubleshooting effort during configuration.  (Again with
  the amateur end user at the other end of the line.)

- Additional problems caused by mismatching prefix configurations.
  (Guess who didn't configure his/her end of the link properly...)

- Additional complications when troubleshooting operational
  installations.  (...amateur...phone...)

- Extra effort if for some future reason all existing tunnels must be
  reconfigured to meet the standards.

Cost of /64 subnet prefixes:

- Additional addresses "wasted".

It's easy to put a price tag on the addresses "wasted" -- just check
what your upstream provider charges for extra addresses -- and it
should be an arbitrarily small \epsilon.  

The cost of non-/64 prefixes isn't easy to put into numbers, but even
if you don't care about probability theory or risk analysis at all it
should be obvious that it is anything but negligible.


And how "wasteful" are /64 subnets on ptp links?  Again this depends
on your particular setup, but here are at least two common scenarios:

- If you have a leaf site with a /48 global routing prefix, split it
  into chunks of /56 or so for individual departments, floors,
  buildings or whatever to limit the routing table entries in your
  company backbone to a reasonable value.  Set aside one /56 for ptp
  links (so you only need a single ACL/packet filter rule for all of
  them). That'll "waste" 256 of your precious 64k subnets, or 0.39%,
  but if you really run out of subnets this way, then your ISP will in
  all likelyhood provide you with another /48.

- If you are a leaf ISP with a /32, first split it in /48s for your
  customers.  Guess how many ptp links per per customer you need on
  the average and allocate one /48 per average ptp link per customer.
  If you need a single link per customer, that'd take a full /48, or
  1/65536, or 0.0015% of your address space, for ptp links.

So in both scenarios this seems a rather marginal "loss".  Of course
there may be other scenarios where the waste of addresses is
significant, but I have never personally seen one.

So considering the additional trouble, and with the environments I've
seen so far in mind, I'd suggest to always go either with a /64 subnet
prefix or arbitrary addresses on any ptp link.


Have a nice weekend everybody,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.


From sthaug at nethelp.no  Fri Jan  8 15:45:26 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Fri, 08 Jan 2010 15:45:26 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <sa77hrsllll.fsf@benedikt-stockebrand.de>
References: <20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<sa77hrsllll.fsf@benedikt-stockebrand.de>
Message-ID: <20100108.154526.41659707.sthaug@nethelp.no>

> In summary, this means that IP stack implementations can't rely on a
> fixed /64 boundary because future standards may come up with new
> address ranges with semantics that require a non-/64 subnet prefix.
> So stack implementations should be coded in a way that supports
> non-/64 prefixes to avoid major rewrites and problems in the future.
> 
> But anything using addresses from the existing ranges may well assume
> a /64 prefix in full compliance with the standards.

Anything assuming only /64 prefixes in the existing ranges would most
likely fail spectacularly given the number non /64 prefixes in use.

For instance, we number our router loopbacks with /128 prefixes from
our global /32. Similarly, our links use /124 prefixes. We have no
intention of changing these to use /64 only.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Sat Jan  9 03:21:28 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Sat, 9 Jan 2010 12:51:28 +1030
Subject: /127 between routers?
In-Reply-To: <m3r5q13jyn.fsf@ursa.amorsen.dk>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<20100108003107.678d9fbb@opy.nosense.org>
	<m3r5q13jyn.fsf@ursa.amorsen.dk>
Message-ID: <20100109125128.4553ae6a@opy.nosense.org>

On Thu, 07 Jan 2010 18:26:08 +0100
Benny Amorsen <benny+usenet at amorsen.dk> wrote:

> Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
> writes:
> 
> > History has shown that creating hard boundaries between the network and
> > node portion (i.e. Classful addressing) may reduce forwarding
> > system flexibility and require mass software/hardware upgrades.
> 
> You can't apply a lesson learned when addresses are scarce to a scenario
> where addresses are plentiful. I bet we would hear the exact same
> concerns if IPv6 addresses were 256-bit.
> 

What do they say? "Those who ignore history are doomed to repeat it."

Sometimes you need to make design decisions based on not so much the
likelyhood of an event happening, but what the consequences are if it
does. So you're probably right, a "hard classful" addressing structure
in 128 or 256 bit IPv6 addresses probably wouldn't encounter any future
issues - but dealing with the consequences if it does are likely to be
near impossible. It's better to be safe than sorry.

Regards,
Mark.

From truman at suspicious.org  Sat Jan  9 03:40:28 2010
From: truman at suspicious.org (Truman Boyes)
Date: Sat, 9 Jan 2010 13:40:28 +1100
Subject: /127 between routers?
In-Reply-To: <20100105152352.GB16923@prolixium.com>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
	<20100105152352.GB16923@prolixium.com>
Message-ID: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>

Juniper is definitely *not* recommending avoiding /64s. Do you have a pointer to where this information came from? I have performed extensive testing of IPv6 forwarding/routing and /64's work just fine.

Truman


On 6/01/2010, at 2:23 AM, Mark Kamichoff wrote:

> On Tue, Jan 05, 2010 at 03:30:06PM +0100, Mikael Abrahamsson wrote:
>> People seem to mostly use /126, /112 or /64 for their p-t-p links.
> 
> I've heard rumors that some router vendors (Juniper, others?) are
> actually recommending to /avoid/ using /64s on point-to-point links
> citing possible performance (ASIC?) issues.
> 
> Has anyone heard something similar?
> 
> - Mark
> 
> -- 
> Mark Kamichoff
> prox at prolixium.com
> http://www.prolixium.com/
> 


From steve at ibctech.ca  Sat Jan  9 04:06:04 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 08 Jan 2010 22:06:04 -0500
Subject: Requests for tunnels
Message-ID: <4B47F29C.7090204@ibctech.ca>

I've run into an interesting situation...

By nature, I'm a friendly, give-everything-I-can type person, but I grew
up without much trust (ie. you build trust with me).

Therefore, if I've been helping someone with an issue on _insert mail
list at something-I-know.org_ and it turns out that they could benefit from
having a VM on a remote network, I give them one temporarily.

The VM is usually an FBSD jail on a box that is situated in my 'hosting'
arm that we have placed outside of our edge. If naughtiness happens, our
standard monitors will easily pick this up.

Over the years, I've had people that I have never met trust me with
routing tables, root/enable access to gear, "change what you need and
call this number if you fsck it up" etc.

This is all ok, because I have respect, loyalty, honour and the general
sense that `they would do it for me`.

As an aside before I go further, I just want to give a quick shout to
Kevin Day of your.org, he.net (particularly Mike who I've mostly dealt
with) and Ross West of connection.ca).

Lately, I've joined a couple of web forums. Although I hate using the
'web' for communication, I thought I'd do it for IPv6-sake. Since, I've
had at least three people asking for BGP tunnelling arrangements.

Even though I don't pay for a lick of my IPv6 transit, I have done this
in the past for specific individuals who were once just like me. These
individuals were people that I met on-list, and who were super-excited,
and the only reason I did this on a temporary basis is so that I could
give them one-to-one live support as they performed their testing
(yes... I stopped my day job to help them understand v6 and get it
working within their network. They just needed to be able to 'ping' from
a remote site to prove it working).

The people who are mailing me that I've `met` on the forums seem *very*
pushy. I offered a test tunnel into my network, and within a few
minutes, they had replied with specific details with the information
that _I_ should configure _my_ gear to comply with.

In essence, to make my long story short, my belief is that we
happy-go-lucky-push-v6 folk are about to run into a situation where
scammers will try to exploit our good nature.

Has this happened to you?

I remember when I originally went v6-live, I had no idea what to ask,
and it was Kevin Day from your.org who stepped up with the details for
me, including creating my route object.

With the experience and knowledge that I have garnered over the two
years since my initial setup, I can say authoritatively that when
someone I am trying to offer the same type of help to is telling me how
to configure *my* gear to suit *their* setup, its not help for v6
testing that they are after.

Thoughts?

Steve

ps. what really pisses me off is when they state that:

"
P.S.

I have marked all address on my router with blue alphabet and your
router with red alphabet.
"

...wtf... do you see red and blue in there? What's worse:

"
Senior Corporate Support Network Engineer
Internet Service & Support Division
Technical & Operation Department
"

..._network engineer_ *emailing* me with HTML and thinks I'll understand
colours? heh




From md at Linux.IT  Sat Jan  9 04:18:20 2010
From: md at Linux.IT (Marco d'Itri)
Date: Sat, 9 Jan 2010 04:18:20 +0100
Subject: Requests for tunnels
In-Reply-To: <4B47F29C.7090204@ibctech.ca>
References: <4B47F29C.7090204@ibctech.ca>
Message-ID: <20100109031820.GB12333@bongo.bofh.it>

On Jan 09, Steve Bertrand <steve at ibctech.ca> wrote:

> Has this happened to you?
Until a couple of years ago at least in Italy it was common to receive
frequent requests for tunnels from people who where obviously not
network professionals, nowadays not so much.
The suspicious requests were all from kids trying to connect to IRCNET
with IPv6, for DoS protection or just to be able to configure lame rDNS.
(Some smarter ones also tried to start small bouncers/shells businesses
on my SixXS tunnels :-) ).

-- 
ciao,
Marco

From steve at ibctech.ca  Sat Jan  9 04:24:10 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 08 Jan 2010 22:24:10 -0500
Subject: /127 between routers?
In-Reply-To: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>	<20100105152352.GB16923@prolixium.com>
	<912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
Message-ID: <4B47F6DA.7080705@ibctech.ca>

Truman Boyes wrote:
> Juniper is definitely *not* recommending avoiding /64s. Do you have a pointer to where this information came from? I have performed extensive testing of IPv6 forwarding/routing and /64's work just fine.

Vendor recommending not using /64?

I envision a snowball in Hell.

I've just finalized on /64 for ptp, and I'm just a small network.

If x vendor states to avoid /64 for ANY situation, good luck to them.

Preferably, I don't want to be getting into the flame of what is best
for ptp.

What is best is what works for you. Personally, I find that /64 eui-64
works great for p-p, pe-p and pe-pe to keep traceroutes happy, and to
make configs almost copy/pasteable (and documentation easy to maintain).

This assumes that you shove your infrastructure links into IGP, along
with your /128 loopbacks.

fwiw, I use /64s on my PE to CE as well (no eui-64). In all honesty, I
don't think I've even ever bothered looking at what a diced up /64 looks
like :)

- one /64 for /128 loopbacks, within a dedicated /48 (per pop)
- one /64 per ptp, within a dedicated /48 (per pop, for all p, pe and ce)
- one /48 into /64s for servers etc (per pop)
- sparse allocation (er. assignment)

...waste? perhaps. Long-term thinking? yes. v4 thinking? no.

Steve

From steve at ibctech.ca  Sat Jan  9 04:42:02 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 08 Jan 2010 22:42:02 -0500
Subject: /127 between routers?
In-Reply-To: <4B47F6DA.7080705@ibctech.ca>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>	<20100105152352.GB16923@prolixium.com>	<912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
	<4B47F6DA.7080705@ibctech.ca>
Message-ID: <4B47FB0A.3000104@ibctech.ca>

Steve Bertrand wrote:
> Truman Boyes wrote:
>> Juniper is definitely *not* recommending avoiding /64s. Do you have a pointer to where this information came from? I have performed extensive testing of IPv6 forwarding/routing and /64's work just fine.
> 
> Vendor recommending not using /64?
> 
> I envision a snowball in Hell.
> 
> I've just finalized on /64 for ptp, and I'm just a small network.
> 
> If x vendor states to avoid /64 for ANY situation, good luck to them.

meh. If my statements were as murky to you as they were to me after I
read my response when it hit the list, I just want to clarify that I
don't, haven't, and never would believe any statement from anyone who
claims that /64's will be obsoleted.

Besides, of course, anyone with an interest at a scale that would make
such an announcement worrisome would publish it properly before the
vendor did. Those on a smaller scale who cared would know where to look
for that notification.

...for some reason, my messages don't make sense to me until after I
send them, even though I've 'previewed' prior to sending ;)

Steve

From james at towardex.com  Sat Jan  9 05:34:37 2010
From: james at towardex.com (James Jun)
Date: Fri, 8 Jan 2010 23:34:37 -0500
Subject: Requests for tunnels
In-Reply-To: <4B47F29C.7090204@ibctech.ca>
References: <4B47F29C.7090204@ibctech.ca>
Message-ID: <01e901ca90e5$0d5b7ad0$28127070$@com>

> 
> In essence, to make my long story short, my belief is that we
> happy-go-lucky-push-v6 folk are about to run into a situation where
> scammers will try to exploit our good nature.
> 
> Has this happened to you?

OCCAID was entirely started back in 2001 as a tunnel operation strictly for
educational purposes between students. It then became a
promote/help-others-get-v6-using-tunnels operation for a few years and went
through the same story as far as v6 was concerned and had the same share of
experiences you're describing.  Its mission over the years had changed
however and there aren't much tunnel activities going on anymore, much less
actively going out and helping others as v6 had matured enough for that to
be any contributing help.

James


From martin at airwire.ie  Sat Jan  9 11:06:33 2010
From: martin at airwire.ie (Martin List-Petersen)
Date: Sat, 09 Jan 2010 10:06:33 +0000
Subject: Requests for tunnels
In-Reply-To: <4B47F29C.7090204@ibctech.ca>
References: <4B47F29C.7090204@ibctech.ca>
Message-ID: <4B485529.90003@airwire.ie>

Steve Bertrand wrote:
> The people who are mailing me that I've `met` on the forums seem *very*
> pushy. I offered a test tunnel into my network, and within a few
> minutes, they had replied with specific details with the information
> that _I_ should configure _my_ gear to comply with.
> 
> In essence, to make my long story short, my belief is that we
> happy-go-lucky-push-v6 folk are about to run into a situation where
> scammers will try to exploit our good nature.
> 
> Has this happened to you?

Yes, it does happen, that we get requests like that. We did get Jeroen
to set one of the SixXS PoP's up in our network, so I'd just refer them
to use that and to comply with the rules attached.

[SNIP]
> 
> ps. what really pisses me off is when they state that:
> 
> "
> P.S.
> 
> I have marked all address on my router with blue alphabet and your
> router with red alphabet.
> "
> 
> ...wtf... do you see red and blue in there? What's worse:
> 
> "
> Senior Corporate Support Network Engineer
> Internet Service & Support Division
> Technical & Operation Department
> "
> 
> ..._network engineer_ *emailing* me with HTML and thinks I'll understand
> colours? heh
> 

Over the years, I've also worked doing premium support for server and
storage hardware vendors. The amount of consultants that call in and
have no clue on what they are at, when they state these and that
certificate, that should have thought them the bits, is amazing.

The more elaborate the titel, the more bullsh*t has been applied and the
more lacking the knowledge is most likely. Just my 2c.

Kind regards,
Martin List-Petersen

From me at benedikt-stockebrand.de  Sat Jan  9 17:58:14 2010
From: me at benedikt-stockebrand.de (Benedikt Stockebrand)
Date: Sat, 09 Jan 2010 16:58:14 +0000
Subject: /127 between routers?
In-Reply-To: <20100108.154526.41659707.sthaug@nethelp.no> (sthaug@nethelp.no's
	message of "Fri, 08 Jan 2010 15:45:26 +0100 (CET)")
References: <20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<sa77hrsllll.fsf@benedikt-stockebrand.de>
	<20100108.154526.41659707.sthaug@nethelp.no>
Message-ID: <sa7d41jmd09.fsf@benedikt-stockebrand.de>

Hello Steinar and list,

sthaug at nethelp.no writes:

>> But anything using addresses from the existing ranges may well assume
>> a /64 prefix in full compliance with the standards.
>
> Anything assuming only /64 prefixes in the existing ranges would most
> likely fail spectacularly given the number non /64 prefixes in use.

absolutely correct, but the only way to gain from a fight with a
vendor of a /64-only product is to stay out of it beforehand---it
doesn't matter whose "fault" it is if something doesn't work.
Customers have an understandable tendency to go with vendors and
service providers that they consider trouble-free.

As we have already seen, RFC 4291 is somewhat misleading as far as
section 2.5.1 is concerned---one has to read beyond that section to
learn about the /64-only issue.  So this is likely to cause trouble in
the future even if somebody took pity right away and updated the RFC
with some clarifications.

The easiest way to stay out of this kind of trouble is by adhering
strictly to the standard while not expecting anybody else to do so.
With a "gain" of not doing so being in many cases "saving" a
sub-percent fraction of an abundant resource it's not exactly a major
investment, at least if you decide to do so when you first start to
design your addressing scheme.

> For instance, we number our router loopbacks with /128 prefixes from
> our global /32. Similarly, our links use /124 prefixes. We have no
> intention of changing these to use /64 only.

Sure, as long as it works for you.  I am certainly not telling you to
change an existing network design, especially when I don't know
anything about the environment you are working in.

>From my particular background however I'd just be afraid that such a
setup eventually blows up in my face the moment I'd least expect it.
Security updates to transit routers or home routers that assume /64
subnets and for some unrelated reason hit the market big time
immediately come to mind.  Call me paranoid, but I've seen these sorts
of things happen.

And, having worked for a large ISP catering primarily for private end
users, I actually see a valid reason for home routers *not* to support
anything but /64 subnets: If your customers can't misconfigure the
subnet prefix, that eliminates yet another potential problem.  If
things work, customers are happy; if things don't work, they'll blame
you (after all, that router works with your competitor's service) and
call your support.  So to an end user ISP a "feature" to configure
arbitrary subnet prefixes just costs you money and reputation.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.


From jimb at jsbc.cc  Sun Jan 10 02:25:01 2010
From: jimb at jsbc.cc (Jim Burwell)
Date: Sat, 09 Jan 2010 17:25:01 -0800
Subject: /127 between routers?
In-Reply-To: <20100108.154526.41659707.sthaug@nethelp.no>
References: <20100106082027.72622e52@opy.nosense.org>	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>	<sa77hrsllll.fsf@benedikt-stockebrand.de>
	<20100108.154526.41659707.sthaug@nethelp.no>
Message-ID: <4B492C6D.20205@jsbc.cc>

On 1/8/2010 06:45, sthaug at nethelp.no wrote:
>> In summary, this means that IP stack implementations can't rely on a
>> fixed /64 boundary because future standards may come up with new
>> address ranges with semantics that require a non-/64 subnet prefix.
>> So stack implementations should be coded in a way that supports
>> non-/64 prefixes to avoid major rewrites and problems in the future.
>>
>> But anything using addresses from the existing ranges may well assume
>> a /64 prefix in full compliance with the standards.
>>     
> Anything assuming only /64 prefixes in the existing ranges would most
> likely fail spectacularly given the number non /64 prefixes in use.
>
> For instance, we number our router loopbacks with /128 prefixes from
> our global /32. Similarly, our links use /124 prefixes. We have no
> intention of changing these to use /64 only.
>   
One also wonders if we're making bad assumptions that non-/64s would not
be supported by vendors at all, or in the hardware 'fast path'.  Seeing
that similar "l3 switching" is already done in ASICs under IPv4, would
it really add cost or R&D time to basically extend this hardware to work
on 128 bits addresses?  I know that in the world of  hardware costs,
pennies matter, but it seems some are assuming that routing beyond /64
would add some sort of significant cost or complexity to the ASICs, but
would it really?  Especially beyond what they already have to do for /64s.

From nick-lists at netability.ie  Sun Jan 10 11:43:17 2010
From: nick-lists at netability.ie (Nick Hilliard)
Date: Sun, 10 Jan 2010 10:43:17 +0000
Subject: /127 between routers?
In-Reply-To: <4B492C6D.20205@jsbc.cc>
References: <20100106082027.72622e52@opy.nosense.org>	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>	<sa77hrsllll.fsf@benedikt-stockebrand.de>	<20100108.154526.41659707.sthaug@nethelp.no>
	<4B492C6D.20205@jsbc.cc>
Message-ID: <4B49AF45.2040501@netability.ie>

On 10/01/2010 01:25, Jim Burwell wrote:
> on 128 bits addresses?  I know that in the world of  hardware costs,
> pennies matter, but it seems some are assuming that routing beyond /64
> would add some sort of significant cost or complexity to the ASICs, but
> would it really?  Especially beyond what they already have to do for /64s.

TCAM is very expensive.  And you need lots more TCAM per prefix for ipv6
than for ipv4.

Nick

From prox at prolixium.com  Sun Jan 10 18:42:47 2010
From: prox at prolixium.com (Mark Kamichoff)
Date: Sun, 10 Jan 2010 12:42:47 -0500
Subject: /127 between routers?
In-Reply-To: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1>
	<alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se>
	<20100105152352.GB16923@prolixium.com>
	<912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
Message-ID: <20100110174246.GA10376@prolixium.com>

Hi Truman - 

On Sat, Jan 09, 2010 at 01:40:28PM +1100, Truman Boyes wrote:
> Juniper is definitely *not* recommending avoiding /64s. Do you have a
> pointer to where this information came from? I have performed
> extensive testing of IPv6 forwarding/routing and /64's work just fine.

Just rumors, mostly, no specific source.  It may have been one of those
corner cases (hopefully!) that won't be seen in most general
deployments.  I've done some rudimentary lab testing with MXes using
/64s as p-t-p links, too, and didn't see any issues.

Didn't mean to start a scare :)

- Mark

-- 
Mark Kamichoff
prox at prolixium.com
http://www.prolixium.com/

From gbonser at seven.com  Sun Jan 10 20:19:37 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 10 Jan 2010 11:19:37 -0800
Subject: /127 between routers?
In-Reply-To: <4B49AF45.2040501@netability.ie>
References: <20100106082027.72622e52@opy.nosense.org>	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>	<sa77hrsllll.fsf@benedikt-stockebrand.de>	<20100108.154526.41659707.sthaug@nethelp.no><4B492C6D.20205@jsbc.cc>
	<4B49AF45.2040501@netability.ie>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F71E3@RWC-EX1.corp.seven.com>



> TCAM is very expensive.  And you need lots more TCAM per prefix for
> ipv6
> than for ipv4.
> 
> Nick

That is going to be another challenge for hardware developers. I suspect
TCAM is going to have to become much less expensive and much more of it
provided in the hardware just for the reason mentioned.

In other words, I don't think the world is going to compromise their
addressing scheme to work around limitations in hardware for long.  The
hardware is going to need to adapt to the new addressing.  The first
vendor that does that will pull everyone else along.  I wouldn't assume
that folks are going to keep building hardware based on IPv4
requirements when more of the world moves to IPv6.



From kiwi at oav.net  Mon Jan 11 10:12:55 2010
From: kiwi at oav.net (Xavier Beaudouin)
Date: Mon, 11 Jan 2010 10:12:55 +0100
Subject: /127 between =?UTF-8?Q?routers=3F?=
In-Reply-To: <20100109125128.4553ae6a@opy.nosense.org>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<20100108003107.678d9fbb@opy.nosense.org>
	<m3r5q13jyn.fsf@ursa.amorsen.dk>
	<20100109125128.4553ae6a@opy.nosense.org>
Message-ID: <e2444d9636cf86b918ddd4a7ad5be5a5@127.0.0.1>

Hi there,

Since I am the one that started this thread, I wanted to clarify why I am
asking that.

First, I wanted to quote Mark :

On Sat, 9 Jan 2010 12:51:28 +1030, Mark Smith

[...]

> What do they say? "Those who ignore history are doomed to repeat it."
> 
> Sometimes you need to make design decisions based on not so much the
> likelyhood of an event happening, but what the consequences are if it
> does. So you're probably right, a "hard classful" addressing structure
> in 128 or 256 bit IPv6 addresses probably wouldn't encounter any future
> issues - but dealing with the consequences if it does are likely to be
> near impossible. It's better to be safe than sorry.

I agree with Mark, we have for now "plenty" of address space, but really,
I don't want to make same error than we all did on IPv4.

Even with a /40 or /48 (that I have for my non profit organization), we
have lots of space, the core network I currently use has lots of point to
point interconnections. On IPv4, we can do that with /30 or even with Cisco
for example /31 (that, I assume very rare).

Now all my routing stuff is done by software, not for the cost, but for
the flexibility and also to provide my organization the possibility to give
some good stuff and be "vendor" free. Avoiding bug, race and so on (yeah
there is fscking bugs also on free/opensource solution I agree !).

Now with a single /48, we can have 65535 /64.
This is quite large... I know, but using a /64 for only 2 ip address, is,
I think a big waste of ressources...

I agree also that some TCAM / Hardware don't like prefix > /64. I noticed
that. So if I will use some hardware vendor thing, I will use /64 in case
to avoid software routing (in this case, I can be LIR, so a /32 will be
given to me).

Also use /127 or /126 between routers, is a good responsibility for all
IPv6 operators. Avoiding asking for to much prefixes in RIPE/ARIN/... is a
good way to be a good citizen...

To get some conclusion within this thread :

- if you use hardware that route that (switch/router): a /64 should be
used and will get good performance
- if you use software routers, you can use whatever you want : /64, /112,
/120, /126 and sometime /127 (but not recommended on Ethernet)
- if you use loopback, you can use /64 or /128 (depending if you use
hardware or software routers)
- if you need RA, you *have to* use /64

Anyway thank you everyone for your replies and your hints.

Sincerely,
Xavier

-- 
Association KAZAR - http://kazar.net/
Non profit hosting for anybody in France

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Mon Jan 11 12:56:50 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Mon, 11 Jan 2010 22:26:50 +1030
Subject: /127 between routers?
In-Reply-To: <e2444d9636cf86b918ddd4a7ad5be5a5@127.0.0.1>
References: <201001060048.00273.mtinka@globaltransit.net>
	<17838240D9A5544AAA5FF95F8D520316074E7C9C@ad-exh01.adhost.lan>
	<20100105192655.GV32226@Space.Net>
	<20100106082027.72622e52@opy.nosense.org>
	<2FE6B9F9-7BF3-4B38-B00B-379DDAA49E16@ed.ac.uk>
	<20100108003107.678d9fbb@opy.nosense.org>
	<m3r5q13jyn.fsf@ursa.amorsen.dk>
	<20100109125128.4553ae6a@opy.nosense.org>
	<e2444d9636cf86b918ddd4a7ad5be5a5@127.0.0.1>
Message-ID: <20100111222650.36a543d5@opy.nosense.org>

Since I'm quoted,

On Mon, 11 Jan 2010 10:12:55 +0100
Xavier Beaudouin <kiwi at oav.net> wrote:

> Hi there,
> 
> Since I am the one that started this thread, I wanted to clarify why I am
> asking that.
> 
> First, I wanted to quote Mark :
> 
> On Sat, 9 Jan 2010 12:51:28 +1030, Mark Smith
> 
> [...]
> 
> > What do they say? "Those who ignore history are doomed to repeat it."
> > 
> > Sometimes you need to make design decisions based on not so much the
> > likelyhood of an event happening, but what the consequences are if it
> > does. So you're probably right, a "hard classful" addressing structure
> > in 128 or 256 bit IPv6 addresses probably wouldn't encounter any future
> > issues - but dealing with the consequences if it does are likely to be
> > near impossible. It's better to be safe than sorry.
> 

You're taking my quote out of context, and I think you might have
missed my point. I was *only* commenting on why I thought there
was soft rather than hard boundaries between the network and node
portion i.e. classless. The cost of going from classful to classless
addressing in the mid 90s was software / hardware upgrades to all
routers in the Internet. I think the possibility of ever doing
that anywhere near as successfully in the future as it was done in the
past is very unlikely. 

> I agree with Mark, we have for now "plenty" of address space, but really,
> I don't want to make same error than we all did on IPv4.
> 

Ever calculated what 2^96 is? That is how much bigger the IPv6 address
space is over IPv4. In no way was I saying that we should be
conservative with IPv6 address space and use > /64 prefixes for node
addresses. Initially I suggested that I was considering /128s for
loopbacks, but after thinking more about it because of this thread,
I've changed my mind. /64s everywhere is the simple, convenient, and
IPv6 Addressing Architecture compliant addressing model.

> Even with a /40 or /48 (that I have for my non profit organization), we
> have lots of space, the core network I currently use has lots of point to
> point interconnections. On IPv4, we can do that with /30 or even with Cisco
> for example /31 (that, I assume very rare).
> 
> Now all my routing stuff is done by software, not for the cost, but for
> the flexibility and also to provide my organization the possibility to give
> some good stuff and be "vendor" free. Avoiding bug, race and so on (yeah
> there is fscking bugs also on free/opensource solution I agree !).
> 
> Now with a single /48, we can have 65535 /64.
> This is quite large... I know, but using a /64 for only 2 ip address, is,
> I think a big waste of ressources...
> 

I don't agree at all. "waste" is something that occurs when you use
a resource without getting some value for it. If you get useful value
from something when you use it, by definition you're not wasting it. If
you use something unnecessarily, only then are you wasting it.

You're not wasting IPv6 address space by using a /64 on a
point-to-point link if the value you are getting (which you can't get in
IPv4) is *simplicity* and *convenience*. I want the simplicity and
convenience of Novell's IPX addressing, like I had in the early 90s,
before I dealt with IPv4. I want to spend my limited brain power on
real problems, not ones that are artificially created by by not
following the IPv6 addressing model, and having to make sure I always
get the prefix length right. I don't want to have to worry about the
values of bits 70 and 71 in the IPv6 address because I've made them
part of the network, rather than the node portion of the address.

I'm happy with address space "waste" - I've been "wasting" Ethernet
addresses for decades. I don't need 46 bits of Ethernet address space
for Ethernet to work. Most Ethernets would only need about 10 bit
addresses, supporting 1024 devices. I only need 48 bit addresses for
the *simplicity* and *convenience* of not having to configure unique
addresses into the card. Think the idea of plug-and-play was invented
in the early 90s? Ethernet had it since 1980, because those extra 32 or
so bits made Ethernet addresses world wide unique - and that's simple
and convenient.

I've even thrown away network cards, and those MAC addresses will
never, ever, ever be used again! That felt like "waste", but then I
thought, "bah, I'm being silly, there's still tons of them left.
They're not even worth my time writing them down to use in the future."

> I agree also that some TCAM / Hardware don't like prefix > /64. I noticed
> that. So if I will use some hardware vendor thing, I will use /64 in case
> to avoid software routing (in this case, I can be LIR, so a /32 will be
> given to me).
> 
> Also use /127 or /126 between routers, is a good responsibility for all
> IPv6 operators. Avoiding asking for to much prefixes in RIPE/ARIN/... is a
> good way to be a good citizen...
> 

I don't think you're being a good citizen, nor are you looking after
your network's owners and end-users if you don't follow the RFCs.

> To get some conclusion within this thread :
> 
> - if you use hardware that route that (switch/router): a /64 should be
> used and will get good performance
> - if you use software routers, you can use whatever you want : /64, /112,
> /120, /126 and sometime /127 (but not recommended on Ethernet)
> - if you use loopback, you can use /64 or /128 (depending if you use
> hardware or software routers)
> - if you need RA, you *have to* use /64
> 

I only support a part of one these recommendations -
"you *have to* use /64", because that's what the RFCs say, and that's
what future RFCs will assume. If far safer to follow them - there's less
likely to be unexpected consequences, which may cause you to have to
renumber to /64s anyway - and I hope you don't have to do it in a hurry
because you're network is suffering from an outage because of those
unexpected consequences.

Sorry if my above sounds like rant, but I want to make absolutely sure
people don't think I support these conclusions.

Regards,
Mark.

From Scott.Beuker at sjrb.ca  Mon Jan 11 18:19:30 2010
From: Scott.Beuker at sjrb.ca (Scott Beuker)
Date: Mon, 11 Jan 2010 10:19:30 -0700
Subject: /127 between routers?
In-Reply-To: <20100110174246.GA10376@prolixium.com>
References: <3954fbd030775be32711bd3404a349ef@127.0.0.1><alpine.DEB.1.10.1001051529320.15329@uplift.swm.pp.se><20100105152352.GB16923@prolixium.com><912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
	<20100110174246.GA10376@prolixium.com>
Message-ID: <1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>

The opposite was indicated to me by Cisco; that on the CRS-1 masks > 64
bits would slow the pps throughput of the ASIC. That statement would in
turn affect loopbacks, too... no more /128s? Meanwhile, 7600s were
explicitly mentioned as not being affected in this same way.

I think if you use anything other than /64s, there will be bumps on the
road ahead for you.

- Scott Beuker




> -----Original Message-----
> From: ipv6-ops-bounces+scott.beuker=sjrb.ca at lists.cluenet.de
> [mailto:ipv6-ops-bounces+scott.beuker=sjrb.ca at lists.cluenet.de] On
> Behalf Of Mark Kamichoff
> Sent: Sunday, January 10, 2010 10:43 AM
> To: Truman Boyes
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: /127 between routers?
> 
> Hi Truman -
> 
> On Sat, Jan 09, 2010 at 01:40:28PM +1100, Truman Boyes wrote:
> > Juniper is definitely *not* recommending avoiding /64s. Do you have
a
> > pointer to where this information came from? I have performed
> > extensive testing of IPv6 forwarding/routing and /64's work just
fine.
> 
> Just rumors, mostly, no specific source.  It may have been one of
those
> corner cases (hopefully!) that won't be seen in most general
> deployments.  I've done some rudimentary lab testing with MXes using
> /64s as p-t-p links, too, and didn't see any issues.
> 
> Didn't mean to start a scare :)
> 
> - Mark
> 
> --
> Mark Kamichoff
> prox at prolixium.com
> http://www.prolixium.com/

From sthaug at nethelp.no  Mon Jan 11 20:55:54 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 11 Jan 2010 20:55:54 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>
References: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
	<20100110174246.GA10376@prolixium.com>
	<1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>
Message-ID: <20100111.205554.74674296.sthaug@nethelp.no>

> The opposite was indicated to me by Cisco; that on the CRS-1 masks > 64
> bits would slow the pps throughput of the ASIC. That statement would in
> turn affect loopbacks, too... no more /128s? Meanwhile, 7600s were
> explicitly mentioned as not being affected in this same way.

I would definitely be sceptical of any such CRS-1 claims until some
supporting evidence can be produced.

> I think if you use anything other than /64s, there will be bumps on the
> road ahead for you.

That train left the station long ago.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From tdurack at gmail.com  Wed Jan 13 16:02:18 2010
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 13 Jan 2010 10:02:18 -0500
Subject: /127 between routers?
In-Reply-To: <20100111.205554.74674296.sthaug@nethelp.no>
References: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
	<20100110174246.GA10376@prolixium.com>
	<1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>
	<20100111.205554.74674296.sthaug@nethelp.no>
Message-ID: <9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>

On Mon, Jan 11, 2010 at 2:55 PM,  <sthaug at nethelp.no> wrote:
>> The opposite was indicated to me by Cisco; that on the CRS-1 masks > 64
>> bits would slow the pps throughput of the ASIC. That statement would in
>> turn affect loopbacks, too... no more /128s? Meanwhile, 7600s were
>> explicitly mentioned as not being affected in this same way.
>
> I would definitely be sceptical of any such CRS-1 claims until some
> supporting evidence can be produced.
>
>> I think if you use anything other than /64s, there will be bumps on the
>> road ahead for you.
>
> That train left the station long ago.
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>

This thread has definitely provided food for thought.

We have currently deployed /128s on loopbacks, and /112s on ptp,
assigned from a site infrastructure /48. /64s are used on everything
else, assigned from a per-site "customer" /48. That maintains a clean
separation between infrastructure and customer space, something that
has been sorely missing from our IPv4 deployments.

The ARIN wiki (http://www.getipv6.info/index.php/IPv6_Addressing_Plans)
encourages this kind of address plan.

rfc4291 is quite clear that only /64s should be used on interfaces.
rfc3627 acknowledges the operational reality that other lengths can
and are being used on ptp interfaces (/127, /126, /120, /112.)

That leaves me in a state of confusion.

I could assign /64s per ptp without difficulty. Should I also assign
/64s per loopback? Should I really being using some form of EUI-64 for
these addresses, to guarantee the interface ID is unique no matter
what the network prefix? What happens when I replace hardware and
EUI-64 changes ptp/loopback addresses?

I'm sure others have gone through this same mental (and design/ops) exercise.

-- 
Tim:>
Sent from Brooklyn, NY, United States

From sthaug at nethelp.no  Wed Jan 13 18:08:18 2010
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 13 Jan 2010 18:08:18 +0100 (CET)
Subject: /127 between routers?
In-Reply-To: <9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>
References: <1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>
	<20100111.205554.74674296.sthaug@nethelp.no>
	<9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>
Message-ID: <20100113.180818.74739924.sthaug@nethelp.no>

> I could assign /64s per ptp without difficulty. Should I also assign
> /64s per loopback? Should I really being using some form of EUI-64 for
> these addresses, to guarantee the interface ID is unique no matter
> what the network prefix? What happens when I replace hardware and
> EUI-64 changes ptp/loopback addresses?

You certainly *don't* want your (globally routable) link addresses to
change just because you replace hardware (e.g. you install a card with
a new MAC address). You *will* get a new link local address, but that's
okay as long as the global address doesn't change.

The obvious conclusion is that the global address should be independent 
of any interface MAC address. It is, of course, possible to create such
addresses which are still in the modified EUI-64 format - I just don't
see any point in doing so when a nice /112, /126 or similar works equally
well.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From Scott.Beuker at sjrb.ca  Wed Jan 13 18:28:52 2010
From: Scott.Beuker at sjrb.ca (Scott Beuker)
Date: Wed, 13 Jan 2010 10:28:52 -0700
Subject: /127 between routers?
In-Reply-To: <9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>
References: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
	<20100110174246.GA10376@prolixium.com>
	<1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>
	<20100111.205554.74674296.sthaug@nethelp.no>
	<9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>
Message-ID: <1EA76BAD7F050648910C041BDDED8CD5155DAE@PRDCG4EXVW01-5.OSS.PRD>

> rfc4291 is quite clear that only /64s should be used on interfaces.
> rfc3627 acknowledges the operational reality that other lengths can
> and are being used on ptp interfaces (/127, /126, /120, /112.)
> 
> That leaves me in a state of confusion.

Me too, and vendors don't seem to have clear answers. It seems at this
point in time we're left to make these early decisions on instinct, and
hope it doesn't come back to bite us.

For me it breaks down to perceived risk versus perceived reward, and I'm
starting to wonder just how much I care about loopback addresses that
are 4-8 characters shorter. I certainly don't care much about saving
space on our backbone infrastructure in a world where your typical home
user will get a /56 and only has 3 hosts.

> I could assign /64s per ptp without difficulty. Should I also assign
> /64s per loopback?

This is the toughest one for me... extremely little traffic will be
forwarded to my ptp prefixes; relatively speaking, much more will be
destined to my loopbacks. So if it's the traffic to the prefix that
matters, should we then be a lot more worried about the loopback
prefixes?

> Should I really being using some form of EUI-64 for
> these addresses, to guarantee the interface ID is unique no matter
> what the network prefix? What happens when I replace hardware and
> EUI-64 changes ptp/loopback addresses?

For what it's worth, we'll use manually assigned addresses everywhere
for infrastructure. Right now, I'm even debating if we should manually
assign the link local addresses (i.e. FE80::1) where we can, to make
troubleshooting easier.

- Scott

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Thu Jan 14 01:57:40 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Thu, 14 Jan 2010 11:27:40 +1030
Subject: /127 between routers?
In-Reply-To: <9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>
References: <912C90B9-A209-488C-93C4-C5E9B0043513@suspicious.org>
	<20100110174246.GA10376@prolixium.com>
	<1EA76BAD7F050648910C041BDDED8CD5155D8A@PRDCG4EXVW01-5.OSS.PRD>
	<20100111.205554.74674296.sthaug@nethelp.no>
	<9e246b4d1001130702x1e539c48ieea6323a6657c729@mail.gmail.com>
Message-ID: <20100114112740.07c38dbf@opy.nosense.org>

On Wed, 13 Jan 2010 10:02:18 -0500
Tim Durack <tdurack at gmail.com> wrote:

> On Mon, Jan 11, 2010 at 2:55 PM,  <sthaug at nethelp.no> wrote:
> >> The opposite was indicated to me by Cisco; that on the CRS-1 masks > 64
> >> bits would slow the pps throughput of the ASIC. That statement would in
> >> turn affect loopbacks, too... no more /128s? Meanwhile, 7600s were
> >> explicitly mentioned as not being affected in this same way.
> >
> > I would definitely be sceptical of any such CRS-1 claims until some
> > supporting evidence can be produced.
> >
> >> I think if you use anything other than /64s, there will be bumps on the
> >> road ahead for you.
> >
> > That train left the station long ago.
> >
> > Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> >
> 
> This thread has definitely provided food for thought.
> 
> We have currently deployed /128s on loopbacks, and /112s on ptp,
> assigned from a site infrastructure /48. /64s are used on everything
> else, assigned from a per-site "customer" /48. That maintains a clean
> separation between infrastructure and customer space, something that
> has been sorely missing from our IPv4 deployments.
> 
> The ARIN wiki (http://www.getipv6.info/index.php/IPv6_Addressing_Plans)
> encourages this kind of address plan.
> 

It's a shame that that document doesn't provide a link to "RFC4291
- IP Version 6 Addressing Architecture", or any of it's ancestors
(RFC3513, RFC2373, RFC1884) . I think it should be referencing them,
stating what the official IPv6 addressing architecture model is, and
stating why it is recommending differently to it. It should also
provide a link to "RFC5375 - IPv6 Unicast Address Assignment
Considerations".

> rfc4291 is quite clear that only /64s should be used on interfaces.
> rfc3627 acknowledges the operational reality that other lengths can
> and are being used on ptp interfaces (/127, /126, /120, /112.)
> 

Sure it acknowledges them, but it doesn't support using them - it's
title is - "/127 Prefix Length Considered Harmful". Section 4,
"Solutions", provides a list of solutions, with the first being

"1. One could use /64 for subnets, including point-to-point links."

it then lists an order of recommended solutions, with 

"1) is definitely the best solution, wherever it is possible."

Section 5, "Other Problems with Long Prefixes" discusses problems of
using non-/64 lengths other than /127s.


> That leaves me in a state of confusion.
> 
> I could assign /64s per ptp without difficulty. Should I also assign
> /64s per loopback? Should I really being using some form of EUI-64 for
> these addresses, to guarantee the interface ID is unique no matter
> what the network prefix? What happens when I replace hardware and
> EUI-64 changes ptp/loopback addresses?
> 


"RFC5375 - IPv6 Unicast Address Assignment Considerations" discusses
these sorts of issues.


> I'm sure others have gone through this same mental (and design/ops) exercise.
> 

It seems to me that what this really is about is trying to be in the
best position, or actually, since "best position" is subjective, the
least costly (in time and therefore usually financial) position in the
future. It's about trying to avoid unexpected and future
renumbering/change of prefix length costs. 

The possible positions or situations are :

1.  you use a variety of node address lengths across your network, and
there are no future consequences - everything works and continues to
work

2.  you use a single node address length (i.e. /64) across your network,
and there are no future consequences - everything works and continues
to work

3.  you use a variety of node address lengths, and you'll have to
renumber to /64s, because you encounter unacceptable issues  e.g.
device performance issues, inability to use features you'd find useful
e.g. SEND.

4.  you use a single node address length, and you'll have to move to
variable length node addresses, because the IPv6 address space ends up
not being as big as it was designed and calculated to be.


Ideally, situations one 1. or 2. will occur, as they're the least
costly. 1. is both initially and operationally slightly more costly than
2. as you'll also have to also accurately manage prefix lengths, which
I think makes 2. the better choice.

The question is, which of those two has the least risk of
devolving into the corresponding 3. or 4? As the fundamental and
authoritative design documents for IPv6 (i.e. the RFCs, not
books, wiki-pages or vendor recommendations - they are all derived or
should be derived from the RFCs), state that for other than addresses
that start with binary 000, the interface ID are required to be 64 bits
in length, it seems to me that situation 2. is the least risky and least
likely to devolve into situation 4. Vendors/developers using RFCs as
authoritative IPV6 documents are going to assume /64s, as are future
protocol developers. 


I see IPv6 as an exercise in both fundamentally overcoming the
constraints of IPv4, but also achieving or better yet, exceeding the
operational simplicity and convenience of more modern protocols than
IPv4, such as Novell's IPX and Appletalk. If IPv6 fails to meet that
simplicity and convenience, then I think the effort of developing and
deploying it would have failed. As how IPv6 is deployed significantly
contributes to how well it meets these goals, I think it is important
to avoid redeploying IPv4 methods and models that just aren't necessary
anymore, and who's driving needs (i.e. lack of address space) have been
specifically designed out of IPv6.


Regards,
Mark.

From michael.dillon at bt.com  Thu Jan 14 08:29:19 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 14 Jan 2010 07:29:19 -0000
Subject: /127 between routers?
In-Reply-To: <20100114112740.07c38dbf@opy.nosense.org>
Message-ID: <28E139F46D45AF49A31950F88C49745804CEEF00@E03MVZ2-UKDY.domain1.systemhost.net>

 
>> The ARIN wiki 
>> (http://www.getipv6.info/index.php/IPv6_Addressing_Plans)
>> encourages this kind of address plan.

> It's a shame that that document doesn't provide a link to "RFC4291
> - IP Version 6 Addressing Architecture", or any of it's ancestors
(RFC3513,
>  RFC2373, RFC1884) . I think it should be referencing them, stating
what the
>  official IPv6 addressing architecture model is, and stating why it is
>  recommending differently to it. It should also provide a link to
"RFC5375 -
>  IPv6 Unicast Address Assignment Considerations".

Actually, the page states quite prominently why it does not follow the
RFCs,
in the Note near the beginning. And it does have a link to RFC 5375.

> The question is, which of those two has the least risk of devolving
into the
> corresponding 3. or 4? As the fundamental and authoritative design
documents
> for IPv6 (i.e. the RFCs, not books, wiki-pages or vendor
recommendations 
> - they are all derived or should be derived from the RFCs),

In a perfect world, the RFCs would be done first, and then people would
build networks according to the RFCs. But in reality, the RFCs are never
done, and often later RFCs incorporate good ideas that are brough to the
table by implementers and network operators. The ARIN wiki attempts to
collect the general consensus of IPv6 network operators as they build
their
FIRST PHASE of the IPv6 Internet. It will all evolve and change, and
when
it does, the set of RFCs describing IPv6 will have changed as well.

-- Michael Dillon

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Thu Jan 14 09:37:50 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Thu, 14 Jan 2010 19:07:50 +1030
Subject: /127 between routers?
In-Reply-To: <28E139F46D45AF49A31950F88C49745804CEEF00@E03MVZ2-UKDY.domain1.systemhost.net>
References: <20100114112740.07c38dbf@opy.nosense.org>
	<28E139F46D45AF49A31950F88C49745804CEEF00@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20100114190750.03486218@opy.nosense.org>

On Thu, 14 Jan 2010 07:29:19 -0000
<michael.dillon at bt.com> wrote:

>  
> >> The ARIN wiki 
> >> (http://www.getipv6.info/index.php/IPv6_Addressing_Plans)
> >> encourages this kind of address plan.
> 
> > It's a shame that that document doesn't provide a link to "RFC4291
> > - IP Version 6 Addressing Architecture", or any of it's ancestors
> (RFC3513,
> >  RFC2373, RFC1884) . I think it should be referencing them, stating
> what the
> >  official IPv6 addressing architecture model is, and stating why it is
> >  recommending differently to it. It should also provide a link to
> "RFC5375 -
> >  IPv6 Unicast Address Assignment Considerations".
> 
> Actually, the page states quite prominently why it does not follow the
> RFCs,
> in the Note near the beginning. And it does have a link to RFC 5375.
> 

Yeah, I'll now be more careful trusting other people's summaries of
documents I haven't read properly. I glanced though it, saw the
various prefix lengths mentioned e.g. /112, and figured it was saying
all the things about variable length interface IDs that some people have
been saying here. 

> > The question is, which of those two has the least risk of devolving
> into the
> > corresponding 3. or 4? As the fundamental and authoritative design
> documents
> > for IPv6 (i.e. the RFCs, not books, wiki-pages or vendor
> recommendations 
> > - they are all derived or should be derived from the RFCs),
> 
> In a perfect world, the RFCs would be done first, and then people would
> build networks according to the RFCs. But in reality, the RFCs are never
> done, and often later RFCs incorporate good ideas that are brough to the
> table by implementers and network operators. The ARIN wiki attempts to
> collect the general consensus of IPv6 network operators as they build
> their
> FIRST PHASE of the IPv6 Internet. It will all evolve and change, and
> when
> it does, the set of RFCs describing IPv6 will have changed as well.
> 

I understand that. Of the 3 versions of the IPv6 Addressing
Architecture RFCs (1884, 3513 and 4291), the 64 bit Interface ID
requirement was specified in RFC3513, published in April 2003, so it's
been part of the IPv6 addressing model for nearly 7 years. 

Regards,
Mark.

From Sam.Wilson at ed.ac.uk  Thu Jan 14 11:56:08 2010
From: Sam.Wilson at ed.ac.uk (Sam Wilson)
Date: Thu, 14 Jan 2010 10:56:08 +0000
Subject: /127 between routers?
In-Reply-To: <20100114190750.03486218@opy.nosense.org>
References: <20100114112740.07c38dbf@opy.nosense.org>
	<28E139F46D45AF49A31950F88C49745804CEEF00@E03MVZ2-UKDY.domain1.systemhost.net>
	<20100114190750.03486218@opy.nosense.org>
Message-ID: <EDBFA613-E074-4FDB-ACD7-AE3019107417@ed.ac.uk>


On 14 Jan 2010, at 08:37, Mark Smith wrote:

> ... Of the 3 versions of the IPv6 Addressing
> Architecture RFCs (1884, 3513 and 4291), the 64 bit Interface ID
> requirement was specified in RFC3513, published in April 2003, so it's
> been part of the IPv6 addressing model for nearly 7 years.

And it is stated as a requirement without invoking RFC 2119  
language.  My first thought is that it is difficult to know what  
force the authors intended that requirement to have.


Sam Wilson
Network Team, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Thu Jan 14 12:30:36 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Thu, 14 Jan 2010 22:00:36 +1030
Subject: /127 between routers?
In-Reply-To: <EDBFA613-E074-4FDB-ACD7-AE3019107417@ed.ac.uk>
References: <20100114112740.07c38dbf@opy.nosense.org>
	<28E139F46D45AF49A31950F88C49745804CEEF00@E03MVZ2-UKDY.domain1.systemhost.net>
	<20100114190750.03486218@opy.nosense.org>
	<EDBFA613-E074-4FDB-ACD7-AE3019107417@ed.ac.uk>
Message-ID: <20100114220036.2b9a08e0@opy.nosense.org>

On Thu, 14 Jan 2010 10:56:08 +0000
Sam Wilson <Sam.Wilson at ed.ac.uk> wrote:

> 
> On 14 Jan 2010, at 08:37, Mark Smith wrote:
> 
> > ... Of the 3 versions of the IPv6 Addressing
> > Architecture RFCs (1884, 3513 and 4291), the 64 bit Interface ID
> > requirement was specified in RFC3513, published in April 2003, so it's
> > been part of the IPv6 addressing model for nearly 7 years.
> 
> And it is stated as a requirement without invoking RFC 2119  
> language.  My first thought is that it is difficult to know what  
> force the authors intended that requirement to have.
> 

It would have been better if they used RFC2119 terms. However, when the
English word "required" is used , it means "not optional". Other words
like "suggested", "optionally", "recommended" etc. would have been used
if a 64 bit interface ID wasn't required.

> 
> Sam Wilson
> Network Team, IT Infrastructure
> Information Services, The University of Edinburgh
> Edinburgh, Scotland, UK
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 

From frnkblk at iname.com  Thu Jan 14 20:00:48 2010
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Thu, 14 Jan 2010 13:00:48 -0600
Subject: IPv6-working freemail status
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>

Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
IPv6-based e-mail transport working?  And a working IPv6 webmail? 

As I plan IPv6 testing later this year it would be good to know what works
and what doesn't.

Frank




From ek at google.com  Thu Jan 14 20:14:24 2010
From: ek at google.com (Erik Kline)
Date: Thu, 14 Jan 2010 11:14:24 -0800
Subject: IPv6-working freemail status
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
Message-ID: <2e8c64261001141114k5feabf62y90bd5d0d12466e09@mail.gmail.com>

2010/1/14 Frank Bulk - iName.com <frnkblk at iname.com>:
> Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
> IPv6-based e-mail transport working? ?And a working IPv6 webmail?
>
> As I plan IPv6 testing later this year it would be good to know what works
> and what doesn't.
>
> Frank

We have not yet launched IPv6 SMTP (neither receipt nor delivery),
POP, nor IMAP.  We do have IPv6 webmail.

From sethm at rollernet.us  Thu Jan 14 20:16:02 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 14 Jan 2010 11:16:02 -0800
Subject: IPv6-working freemail status
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
Message-ID: <4B4F6D72.4000602@rollernet.us>

Frank Bulk - iName.com wrote:
> Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
> IPv6-based e-mail transport working?  And a working IPv6 webmail? 
> 
> As I plan IPv6 testing later this year it would be good to know what works
> and what doesn't.
> 

None that I'm aware of at the transport level. Speaking for myself, yes,
but not free.

~Seth

From frnkblk at iname.com  Thu Jan 14 20:28:52 2010
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Thu, 14 Jan 2010 13:28:52 -0600
Subject: IPv6-working freemail status
In-Reply-To: <2e8c64261001141114k5feabf62y90bd5d0d12466e09@mail.gmail.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<2e8c64261001141114k5feabf62y90bd5d0d12466e09@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACeGPeLeHfSTI+d/nLV4stCAQAAAAA=@iname.com>

Good to know, thanks.

Any target dates?

Frank

-----Original Message-----
From: Erik Kline [mailto:ek at google.com] 
Sent: Thursday, January 14, 2010 1:14 PM
To: frnkblk at iname.com
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: IPv6-working freemail status

2010/1/14 Frank Bulk - iName.com <frnkblk at iname.com>:
> Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
> IPv6-based e-mail transport working?  And a working IPv6 webmail?
>
> As I plan IPv6 testing later this year it would be good to know what works
> and what doesn't.
>
> Frank

We have not yet launched IPv6 SMTP (neither receipt nor delivery),
POP, nor IMAP.  We do have IPv6 webmail.


From ek at google.com  Thu Jan 14 20:52:25 2010
From: ek at google.com (Erik Kline)
Date: Thu, 14 Jan 2010 11:52:25 -0800
Subject: IPv6-working freemail status
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACeGPeLeHfSTI+d/nLV4stCAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<2e8c64261001141114k5feabf62y90bd5d0d12466e09@mail.gmail.com>
	<!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACeGPeLeHfSTI+d/nLV4stCAQAAAAA=@iname.com>
Message-ID: <2e8c64261001141152v3e4e2975td8484f2d43b1b029@mail.gmail.com>

Nothing I can mention, obviously/unfortunately.  But you remind me I
should check on these things...been far too focused on other bits
recently.

2010/1/14 Frank Bulk - iName.com <frnkblk at iname.com>:
> Good to know, thanks.
>
> Any target dates?
>
> Frank
>
> -----Original Message-----
> From: Erik Kline [mailto:ek at google.com]
> Sent: Thursday, January 14, 2010 1:14 PM
> To: frnkblk at iname.com
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: IPv6-working freemail status
>
> 2010/1/14 Frank Bulk - iName.com <frnkblk at iname.com>:
>> Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
>> IPv6-based e-mail transport working? ?And a working IPv6 webmail?
>>
>> As I plan IPv6 testing later this year it would be good to know what works
>> and what doesn't.
>>
>> Frank
>
> We have not yet launched IPv6 SMTP (neither receipt nor delivery),
> POP, nor IMAP. ?We do have IPv6 webmail.
>
>

From sm at resistor.net  Thu Jan 14 21:37:37 2010
From: sm at resistor.net (SM)
Date: Thu, 14 Jan 2010 12:37:37 -0800
Subject: IPv6-working freemail status
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84B
	MpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
Message-ID: <6.2.5.6.2.20100114123105.07f21580@resistor.net>

At 11:00 14-01-10, Frank Bulk - iName.com wrote:
>Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
>IPv6-based e-mail transport working?  And a working IPv6 webmail?

These freemail providers currently do not support SMTP over IPv6.

Some mail filters unfortunately consider MX hosts resolving to IPv6 
addresses as invalid and the message is rejected because of 
that.  You won't encounter that problem with the freemail providers 
you mentioned.

Regards,
-sm 


From md at Linux.IT  Thu Jan 14 21:59:52 2010
From: md at Linux.IT (Marco d'Itri)
Date: Thu, 14 Jan 2010 21:59:52 +0100
Subject: IPv6-working freemail status
In-Reply-To: <6.2.5.6.2.20100114123105.07f21580@resistor.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
Message-ID: <20100114205952.GA3872@bongo.bofh.it>

On Jan 14, SM <sm at resistor.net> wrote:

> Some mail filters unfortunately consider MX hosts resolving to IPv6  
> addresses as invalid and the message is rejected because of that.  You 
> won't encounter that problem with the freemail providers you mentioned.
I doubt that this will be a problem since nowadays some versions of
Microsoft Exchange add Received headers with link-local v6 addresses to
all outgoing messages (even if the server does not have v6
connectivity).

-- 
ciao,
Marco

From berni at birkenwald.de  Thu Jan 14 22:14:04 2010
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Thu, 14 Jan 2010 22:14:04 +0100
Subject: IPv6-working freemail status
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
Message-ID: <4B4F891C.7000609@birkenwald.de>

On 14.01.2010 20:00, Frank Bulk - iName.com wrote:

Hi,

> Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
> IPv6-based e-mail transport working?  And a working IPv6 webmail?
>
> As I plan IPv6 testing later this year it would be good to know what works
> and what doesn't.

Freenet.de supports IPv6 for SMTP in&out, POP3 and IMAP.

Not sure about Webmail (probably not).

Best Regards,
Bernhard

From gert at space.net  Thu Jan 14 22:58:39 2010
From: gert at space.net (Gert Doering)
Date: Thu, 14 Jan 2010 22:58:39 +0100
Subject: IPv6-working freemail status
In-Reply-To: <6.2.5.6.2.20100114123105.07f21580@resistor.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
Message-ID: <20100114215839.GD32226@Space.Net>

Hi,

On Thu, Jan 14, 2010 at 12:37:37PM -0800, SM wrote:
> At 11:00 14-01-10, Frank Bulk - iName.com wrote:
> >Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
> >IPv6-based e-mail transport working?  And a working IPv6 webmail?
> 
> These freemail providers currently do not support SMTP over IPv6.
> 
> Some mail filters unfortunately consider MX hosts resolving to IPv6 
> addresses as invalid and the message is rejected because of 
> that.  

Can you name some specifics?  I've had an MX with IPv6 record since
5 years or so, and have not encountered mail unreachables due to that.

> You won't encounter that problem with the freemail providers 
> you mentioned.

I've heard that excuse before.  "Something might break, let's stick to
legacy IP!!" (instead of "find out what breaks, and go fix it").  *sigh*.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From balla at staff.spin.it  Thu Jan 14 23:09:37 2010
From: balla at staff.spin.it (Emanuele Balla)
Date: Thu, 14 Jan 2010 23:09:37 +0100
Subject: IPv6-working freemail status
In-Reply-To: <20100114215839.GD32226@Space.Net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net>
Message-ID: <4B4F9621.2050109@staff.spin.it>

On 1/14/10 10:58 PM, Gert Doering wrote:

>> Some mail filters unfortunately consider MX hosts resolving to IPv6 
>> addresses as invalid and the message is rejected because of 
>> that.  
> 
> Can you name some specifics?  I've had an MX with IPv6 record since
> 5 years or so, and have not encountered mail unreachables due to that.

At least some versions of Barracuda stuff out there seem to misparse
Received headers and claim some random IPv6 address as blacklisted by
${RANDOM_DNSBL}.

I see this happening once a week, more or less, in my customers
complaints. Not much of an issue, anyway.

-- 
# Emanuele Balla            #                            #
# System & Network Engineer # Cell:  +39 348 7747907     #
# Spin s.r.l.               # Phone: +39 040 9869090     #
# Trieste                   # Email: balla at staff.spin.it #

From sm at resistor.net  Fri Jan 15 00:11:33 2010
From: sm at resistor.net (SM)
Date: Thu, 14 Jan 2010 15:11:33 -0800
Subject: IPv6-working freemail status
In-Reply-To: <20100114215839.GD32226@Space.Net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net>
Message-ID: <6.2.5.6.2.20100114142037.09a45bc8@resistor.net>

Hi Gert,
At 13:58 14-01-10, Gert Doering wrote:
>Can you name some specifics?  I've had an MX with IPv6 record since
>5 years or so, and have not encountered mail unreachables due to that.

That occurred two years ago with domains hosted with Postini.  There 
were also some other cases where people verified whether the IP 
address the MX host resolves to is reachable.  The test omitted to 
take IPv6 addresses into consideration.  This is different from 
message header parsing.

>I've heard that excuse before.  "Something might break, let's stick to
>legacy IP!!" (instead of "find out what breaks, and go fix it").  *sigh*.

Something is already broken.  You can either find out what is broken 
and fix it or else keep thinking that it can only be dotted quad.

Regards,
-sm 


From ipv6-ops+phil at spodhuis.org  Fri Jan 15 00:16:09 2010
From: ipv6-ops+phil at spodhuis.org (Phil Pennock)
Date: Thu, 14 Jan 2010 15:16:09 -0800
Subject: IPv6-working freemail status
In-Reply-To: <4B4F9621.2050109@staff.spin.it>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net> <4B4F9621.2050109@staff.spin.it>
Message-ID: <20100114231609.GA8680@redoubt.spodhuis.org>

On 2010-01-14 at 23:09 +0100, Emanuele Balla wrote:
> At least some versions of Barracuda stuff out there seem to misparse
> Received headers and claim some random IPv6 address as blacklisted by
> ${RANDOM_DNSBL}.

On exim-users, there's been at least one report that an IPv6 address put
into a DNSxL lookup, following the correct nibble rules, results in the
DNSxL server returning false positives.

I believe that it was rbldnsd which was broken but am not completely
sure.

The workaround is easy, you just only permit DNSxL lookups for IPv4
addresses and implicitly whitelist IPv6; not a long-term solution,
obviously.  (condition = ${if isip4{$sender_host_address}}).

-Phil

From ocl at gih.com  Fri Jan 15 00:16:13 2010
From: ocl at gih.com (Olivier MJ Crepin-Leblond)
Date: Fri, 15 Jan 2010 00:16:13 +0100
Subject: IPv6-working freemail status
In-Reply-To: <6.2.5.6.2.20100114123105.07f21580@resistor.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
Message-ID: <4B4FA5BD.9040505@gih.com>



Le 14/01/2010 21:37, SM a ?crit :
> At 11:00 14-01-10, Frank Bulk - iName.com wrote:
>> Which of the freemail providers (Google, Hotmail, AOL, Yahoo!, etc) have
>> IPv6-based e-mail transport working?  And a working IPv6 webmail?
>
> These freemail providers currently do not support SMTP over IPv6.
>
> Some mail filters unfortunately consider MX hosts resolving to IPv6 
> addresses as invalid and the message is rejected because of that.  You 
> won't encounter that problem with the freemail providers you mentioned.
>

I've encountered filters checking for a reverse DNS. As long as both 
IPv4 & IPv6 rDNS works, it would be inappropriate for a mail filter to 
trigger.
Also - I haven't encountered IPv6-only MX hosts yet. I would have 
assumed that most current systems supporting v6 are dual stack.

Kind regards,

Olivier

-- 
Olivier Cr?pin-Leblond, PhD
http://www.gih.com/ocl.html


From gert at space.net  Fri Jan 15 09:58:21 2010
From: gert at space.net (Gert Doering)
Date: Fri, 15 Jan 2010 09:58:21 +0100
Subject: IPv6-working freemail status
In-Reply-To: <6.2.5.6.2.20100114142037.09a45bc8@resistor.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net>
	<6.2.5.6.2.20100114142037.09a45bc8@resistor.net>
Message-ID: <20100115085821.GH32226@Space.Net>

Hi,

On Thu, Jan 14, 2010 at 03:11:33PM -0800, SM wrote:
> Something is already broken.  You can either find out what is broken 
> and fix it [..]

Yes.  That's our approach to things.  Enable v6, see the breakage, fix it.

(And no, our corporate MX *still* does not have v6, because a well-known 
anti-spam appliance is not there yet - but progress is being made, so 
hopefully "real soon"...).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100115/7d71f669/attachment.bin 

From Sam.Wilson at ed.ac.uk  Fri Jan 15 12:11:40 2010
From: Sam.Wilson at ed.ac.uk (Sam Wilson)
Date: Fri, 15 Jan 2010 11:11:40 +0000
Subject: IPv6-working freemail status
In-Reply-To: <20100114205952.GA3872@bongo.bofh.it>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114205952.GA3872@bongo.bofh.it>
Message-ID: <1513A560-73A9-4A6A-9CEB-9AE74BC16EAA@ed.ac.uk>


On 14 Jan 2010, at 20:59, Marco d'Itri wrote:

> On Jan 14, SM <sm at resistor.net> wrote:
>
>> Some mail filters unfortunately consider MX hosts resolving to IPv6
>> addresses as invalid and the message is rejected because of that.   
>> You
>> won't encounter that problem with the freemail providers you  
>> mentioned.
> I doubt that this will be a problem since nowadays some versions of
> Microsoft Exchange add Received headers with link-local v6  
> addresses to
> all outgoing messages (even if the server does not have v6
> connectivity).

And if you manage to remove IPv6 completely (with registry edits),  
not just disable it, then Exchange starts putting in 169.254  
addresses.  But that's probably off-topic.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From ghen at telenet.be  Fri Jan 15 12:42:19 2010
From: ghen at telenet.be (Geert Hendrickx)
Date: Fri, 15 Jan 2010 12:42:19 +0100
Subject: IPv6-working freemail status
In-Reply-To: <20100114205952.GA3872@bongo.bofh.it>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114205952.GA3872@bongo.bofh.it>
Message-ID: <20100115114219.GA4936@boris.ghen.be>

On Thu, Jan 14, 2010 at 09:59:52PM +0100, Marco d'Itri wrote:
> On Jan 14, SM <sm at resistor.net> wrote:
> 
> > Some mail filters unfortunately consider MX hosts resolving to IPv6  
> > addresses as invalid and the message is rejected because of that.  You 
> > won't encounter that problem with the freemail providers you mentioned.
> I doubt that this will be a problem since nowadays some versions of
> Microsoft Exchange add Received headers with link-local v6 addresses to
> all outgoing messages (even if the server does not have v6 connectivity).


I've seen content filters mis-interpreting those very headers and marking
mails as spam because of that (but it was easily fixed).


	Geert


-- 
Geert Hendrickx  -=-  ghen at telenet.be  -=-  PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

From berni at birkenwald.de  Mon Jan 18 23:20:42 2010
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Mon, 18 Jan 2010 23:20:42 +0100
Subject: OpenVPN IPv6 payload patch
Message-ID: <4B54DEBA.9090107@birkenwald.de>

Hi,

I think this is on-topic here as well.

-------- Original Message --------
Subject: [Openvpn-users] [ANNOUNCE] IPv6 payload patch
Date: Mon, 18 Jan 2010 23:09:52 +0100
From: Bernhard Schmidt <berni at birkenwald.de>
To: openvpn-users at lists.sourceforge.net,	openvpn-devel at lists.sourceforge.net
CC: gert at greenie.muc.de

Hello everyone,

up to now OpenVPN only supports transporting IPv6 data through a
point-to-multipoint (tls-server/tls-client mode) using tap-interfaces,
which emulate a virtual ethernet device. The preferred tun-mode does not
support any IPv6, because the in-process routing engine does not
understand IPv6 addressing.

After planning to force a student to write this part of code (who
unfortunately sensed our plot and ran for his life) Gert Doering finally
yielded to our begging and promises of beer and wrote the code.

So here we go. This patch implements pretty much everything you need for
a decent IPv6 VPN-concentrator setup, including autoconfiguration of the
client and routing of arbitrary subnets from the client to the server or
from the server to the client.

The patch (on stock upstream OpenVPN) and some rough documentation can
be found at http://www.greenie.net/ipv6/openvpn.html . We are also
maintaining the code in git to ease development. There are a public
git-repository on my personal git server

git://git.birkenwald.de/openvpn.git with the following branches:
* upstream (fetched from http://github.com/jjo/openvpn-ipv6/ stock
   branch, which again comes from git-svn from the OpenVPN repository)
* jjo-ipv6 (fetched again from jjo master branch, which is upstream
   with the additional patches for IPv6 _transport_ (not related to this
   project)
* gert-ipv6 (upstream + gert's patches for IPv6 payload)

There is also a jjo+gert branch which merges both branches.  There was a
small conflict in one function in mroute.c, but that is only cosmetical.
We're working on getting that aligned.

Additionally I have built Debian/Ubuntu binary packages (no guarantees
whatsoever) which are available on my Launchpad PPA at
https://launchpad.net/~berni/+archive/ipv6 . They say Ubuntu
Intrepid/Karmic but run on Debian Lenny just fine. They are however
based on the Debian OpenVPN package from testing (which also includes
jjo's IPv6 transport patch), so they might introduce additional bugs not
present in the stable series. Use at your own risk.

The patched binaries have been tested on a number of OpenVPN installations,
with a large number of different clients (mostly unpatched, some with
IPv6 patches) connecting to patched servers, and we have not seen any
instabilities yet.  So we consider this "safe for more wider-scale testing
and peer review".

So what's left to do? Windows support for IPv6 is completely
unimplemented at the moment, that part of the code would love to see
someone familiar with the platform. Documentation (which is my primary
responsibility, so I'd love to see patches from all of you :-) ) is
pretty much missing.  And of course, testing, testing, testing...

We would love to hear your thoughts and results about it.

Best Regards,
Bernhard and Gert

From martin at airwire.ie  Tue Jan 19 00:48:10 2010
From: martin at airwire.ie (Martin List-Petersen)
Date: Mon, 18 Jan 2010 23:48:10 +0000
Subject: OpenVPN IPv6 payload patch
In-Reply-To: <4B54DEBA.9090107@birkenwald.de>
References: <4B54DEBA.9090107@birkenwald.de>
Message-ID: <4B54F33A.7000301@airwire.ie>

> Additionally I have built Debian/Ubuntu binary packages (no guarantees
> whatsoever) which are available on my Launchpad PPA at
> https://launchpad.net/~berni/+archive/ipv6 . They say Ubuntu
> Intrepid/Karmic but run on Debian Lenny just fine. They are however
> based on the Debian OpenVPN package from testing (which also includes
> jjo's IPv6 transport patch), so they might introduce additional bugs not
> present in the stable series. Use at your own risk.

Hi,
I've tested this with a Debian server (lenny) and Ubuntu client (Karmic)
and it works out of the box.

Congratulations.

One thing, and I guess this requires modifications in
network-manager-openvpn: It also works, BUT ignores "push
route-ipv6-gateway" and "push route-ipv6 ...." (obviously routes pushed
from the server) entirely.

The ipv6 address will however be configured without glitch.

Kind regards,
Martin List-Petersen


From fw at deneb.enyo.de  Sat Jan 23 13:06:49 2010
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 23 Jan 2010 13:06:49 +0100
Subject: IPv6-working freemail status
In-Reply-To: <20100114215839.GD32226@Space.Net> (Gert Doering's message of
	"Thu, 14 Jan 2010 22:58:39 +0100")
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net>
Message-ID: <87fx5x9g9y.fsf@mid.deneb.enyo.de>

* Gert Doering:

>> Some mail filters unfortunately consider MX hosts resolving to IPv6 
>> addresses as invalid and the message is rejected because of 
>> that.  
>
> Can you name some specifics?  I've had an MX with IPv6 record since
> 5 years or so, and have not encountered mail unreachables due to that.

MX entries which point to a name lacking an A record cause relatively
widespread interoperability issues, due to sender domain verification
failures.

From jtk at titania.net  Sat Jan 23 20:01:25 2010
From: jtk at titania.net (Joseph T. Klein)
Date: Sat, 23 Jan 2010 13:01:25 -0600
Subject: IPv6-working freemail status
In-Reply-To: <87fx5x9g9y.fsf@mid.deneb.enyo.de>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>	<6.2.5.6.2.20100114123105.07f21580@resistor.net>	<20100114215839.GD32226@Space.Net>
	<87fx5x9g9y.fsf@mid.deneb.enyo.de>
Message-ID: <4B5B4785.40505@titania.net>

Could this be a quad A reverse issue?

I have been running IPv6 (Sendmail) SNMP for some time.

I have been seeing more rejections based on the AAAA record, took me a
couple of passes to figure out why. By default XP SP2 is set with
anonymous address interface identifiers. I had one XP system so set and
had fixed IPv6 reverses on all other systems.

In the last month we started to see rejected e-mail from mail sent by
that system. I assume that some new widespread software patch just
started to check the AAAA reverses.

BTW the switch is:

netsh interface ipv6 set privacy state=disable

or

ipv6 -p gpu UseTemporaryAddresses no


On 1/23/10 6:06 AM, Florian Weimer wrote:
> * Gert Doering:
> 
>>> Some mail filters unfortunately consider MX hosts resolving to IPv6 
>>> addresses as invalid and the message is rejected because of 
>>> that.  
>>
>> Can you name some specifics?  I've had an MX with IPv6 record since
>> 5 years or so, and have not encountered mail unreachables due to that.
> 
> MX entries which point to a name lacking an A record cause relatively
> widespread interoperability issues, due to sender domain verification
> failures.

-- 
Joseph T. Klein
"A community is democratic only when the humblest and weakest person
 can enjoy the highest civil, economic, and social rights that the
 biggest and most powerful possess."
                                               -- A. Philip Randolph
Google Voice: (414) 375-0313

From tony at lava.net  Sat Jan 23 20:23:04 2010
From: tony at lava.net (Antonio Querubin)
Date: Sat, 23 Jan 2010 09:23:04 -1000 (HST)
Subject: IPv6-working freemail status
In-Reply-To: <4B5B4785.40505@titania.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net>
	<87fx5x9g9y.fsf@mid.deneb.enyo.de> <4B5B4785.40505@titania.net>
Message-ID: <alpine.OSX.2.00.1001230918300.776@cust11794.lava.net>

On Sat, 23 Jan 2010, Joseph T. Klein wrote:

> I have been seeing more rejections based on the AAAA record, took me a
> couple of passes to figure out why. By default XP SP2 is set with
> anonymous address interface identifiers. I had one XP system so set and
> had fixed IPv6 reverses on all other systems.
>
> In the last month we started to see rejected e-mail from mail sent by
> that system. I assume that some new widespread software patch just
> started to check the AAAA reverses.

Is that a user workstation whose mail client just uses only one outgoing 
smtp server?  Or is it operating as a mail relay for a bunch of users? 
Have you been able to isolate it to specific mail servers/domains?

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net

From jtk at titania.net  Sat Jan 23 22:29:50 2010
From: jtk at titania.net (Joseph T. Klein)
Date: Sat, 23 Jan 2010 15:29:50 -0600
Subject: IPv6-working freemail status
In-Reply-To: <alpine.OSX.2.00.1001230918300.776@cust11794.lava.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>	<6.2.5.6.2.20100114123105.07f21580@resistor.net>	<20100114215839.GD32226@Space.Net>	<87fx5x9g9y.fsf@mid.deneb.enyo.de>
	<4B5B4785.40505@titania.net>
	<alpine.OSX.2.00.1001230918300.776@cust11794.lava.net>
Message-ID: <4B5B6A4E.80700@titania.net>

This sender is an XP SP2 workstation using Thunderbird relayed via a
Freebsd 8.0 stable Sendmail. So far as I can tell the same setup did not
have any issues prior to December. When I turned off the random address
"feature" and had a valid reverse, the mail went through without a hitch.

The sanitized domains with the issue:

Jan 21 01:55:54 xxxxx sendmail[71978]: o0L1tmYA071978:
ruleset=check_rcpt, arg1=<xxxxx at mindspring.com>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:498c:693b:6bb5:8794], reject=550 5.7.1
<xxxxx at mindspring.com>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:498c:693b:6bb5:8794]
Jan 19 03:35:58 monet sendmail[49301]: o0J3ZrQk049301:
ruleset=check_rcpt, arg1=<xxxxx at tds.net>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0], reject=550 5.7.1
<xxxxx at tds.net>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0]
Jan 19 03:54:00 monet sendmail[49383]: o0J3rxmm049383:
ruleset=check_rcpt, arg1=<xxxxx at hotmail.com>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0], reject=550 5.7.1
<xxxxx at hotmail.com>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0]
Jan 18 03:29:31 monet sendmail[84989]: o0I3THvc084989:
ruleset=check_rcpt, arg1=<xxxxx at charter.net>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
<xxxxx at charter.net>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
Jan 18 18:41:56 monet sendmail[39677]: o0IIfn3F039677:
ruleset=check_rcpt, arg1=<xxxxx at purinamills.com>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
<xxxxx at purinamills.com>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
Jan 18 18:49:24 monet sendmail[40048]: o0IInLSv040048:
ruleset=check_rcpt, arg1=<xxxxx at landolakes.com>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
<xxxxx at landolakes.com>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
Jan 18 18:52:25 monet sendmail[40310]: o0IIqG35040310:
ruleset=check_rcpt, arg1=<xxxxx at landolakes.com>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
<xxxxx at landolakes.com>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
Jan 18 18:54:06 monet sendmail[40408]: o0IIs6ql040408:
ruleset=check_rcpt, arg1=<xxxxx at purinamills.com>,
relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
<xxxxx at purinamills.com>... Relaying denied. IP name lookup failed
[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]

On 1/23/10 1:23 PM, Antonio Querubin wrote:
> On Sat, 23 Jan 2010, Joseph T. Klein wrote:
> 
>> I have been seeing more rejections based on the AAAA record, took me a
>> couple of passes to figure out why. By default XP SP2 is set with
>> anonymous address interface identifiers. I had one XP system so set and
>> had fixed IPv6 reverses on all other systems.
>>
>> In the last month we started to see rejected e-mail from mail sent by
>> that system. I assume that some new widespread software patch just
>> started to check the AAAA reverses.
> 
> Is that a user workstation whose mail client just uses only one outgoing
> smtp server?  Or is it operating as a mail relay for a bunch of users?
> Have you been able to isolate it to specific mail servers/domains?
> 
> Antonio Querubin
> 808-545-5282 x3003
> e-mail/xmpp:  tony at lava.net

-- 
Joseph T. Klein
"A community is democratic only when the humblest and weakest person
 can enjoy the highest civil, economic, and social rights that the
 biggest and most powerful possess."
                                               -- A. Philip Randolph
Google Voice: (414) 375-0313

From jtk at titania.net  Sat Jan 23 22:43:18 2010
From: jtk at titania.net (Joseph T. Klein)
Date: Sat, 23 Jan 2010 15:43:18 -0600
Subject: IPv6-working freemail status
In-Reply-To: <4B5B6A4E.80700@titania.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>	<6.2.5.6.2.20100114123105.07f21580@resistor.net>	<20100114215839.GD32226@Space.Net>	<87fx5x9g9y.fsf@mid.deneb.enyo.de>	<4B5B4785.40505@titania.net>	<alpine.OSX.2.00.1001230918300.776@cust11794.lava.net>
	<4B5B6A4E.80700@titania.net>
Message-ID: <4B5B6D76.8020607@titania.net>

OK I guess I'm being a bonehead ... clearly in thinking about this it
must be an internal change caused by my me.

On 1/23/10 3:29 PM, Joseph T. Klein wrote:
> This sender is an XP SP2 workstation using Thunderbird relayed via a
> Freebsd 8.0 stable Sendmail. So far as I can tell the same setup did not
> have any issues prior to December. When I turned off the random address
> "feature" and had a valid reverse, the mail went through without a hitch.
> 
> The sanitized domains with the issue:
> 
> Jan 21 01:55:54 xxxxx sendmail[71978]: o0L1tmYA071978:
> ruleset=check_rcpt, arg1=<xxxxx at mindspring.com>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:498c:693b:6bb5:8794], reject=550 5.7.1
> <xxxxx at mindspring.com>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:498c:693b:6bb5:8794]
> Jan 19 03:35:58 monet sendmail[49301]: o0J3ZrQk049301:
> ruleset=check_rcpt, arg1=<xxxxx at tds.net>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0], reject=550 5.7.1
> <xxxxx at tds.net>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0]
> Jan 19 03:54:00 monet sendmail[49383]: o0J3rxmm049383:
> ruleset=check_rcpt, arg1=<xxxxx at hotmail.com>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0], reject=550 5.7.1
> <xxxxx at hotmail.com>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:ed43:ccb2:1418:55c0]
> Jan 18 03:29:31 monet sendmail[84989]: o0I3THvc084989:
> ruleset=check_rcpt, arg1=<xxxxx at charter.net>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
> <xxxxx at charter.net>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
> Jan 18 18:41:56 monet sendmail[39677]: o0IIfn3F039677:
> ruleset=check_rcpt, arg1=<xxxxx at purinamills.com>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
> <xxxxx at purinamills.com>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
> Jan 18 18:49:24 monet sendmail[40048]: o0IInLSv040048:
> ruleset=check_rcpt, arg1=<xxxxx at landolakes.com>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
> <xxxxx at landolakes.com>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
> Jan 18 18:52:25 monet sendmail[40310]: o0IIqG35040310:
> ruleset=check_rcpt, arg1=<xxxxx at landolakes.com>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
> <xxxxx at landolakes.com>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
> Jan 18 18:54:06 monet sendmail[40408]: o0IIs6ql040408:
> ruleset=check_rcpt, arg1=<xxxxx at purinamills.com>,
> relay=[IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4], reject=550 5.7.1
> <xxxxx at purinamills.com>... Relaying denied. IP name lookup failed
> [IPv6:xxxx:xxxx:xxxx:xxxx:6857:1f36:cf4a:cca4]
> 
> On 1/23/10 1:23 PM, Antonio Querubin wrote:
>> On Sat, 23 Jan 2010, Joseph T. Klein wrote:
>>
>>> I have been seeing more rejections based on the AAAA record, took me a
>>> couple of passes to figure out why. By default XP SP2 is set with
>>> anonymous address interface identifiers. I had one XP system so set and
>>> had fixed IPv6 reverses on all other systems.
>>>
>>> In the last month we started to see rejected e-mail from mail sent by
>>> that system. I assume that some new widespread software patch just
>>> started to check the AAAA reverses.
>>
>> Is that a user workstation whose mail client just uses only one outgoing
>> smtp server?  Or is it operating as a mail relay for a bunch of users?
>> Have you been able to isolate it to specific mail servers/domains?
>>
>> Antonio Querubin
>> 808-545-5282 x3003
>> e-mail/xmpp:  tony at lava.net
> 

-- 
Joseph T. Klein
"A community is democratic only when the humblest and weakest person
 can enjoy the highest civil, economic, and social rights that the
 biggest and most powerful possess."
                                               -- A. Philip Randolph
Google Voice: (414) 375-0313

From fw at deneb.enyo.de  Sat Jan 23 23:10:51 2010
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 23 Jan 2010 23:10:51 +0100
Subject: IPv6-working freemail status
In-Reply-To: <4B5B4785.40505@titania.net> (Joseph T. Klein's message of "Sat, 
	23 Jan 2010 13:01:25 -0600")
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAzsoS3Kez3RaqIKy/7OQyoAQAAAAA=@iname.com>
	<6.2.5.6.2.20100114123105.07f21580@resistor.net>
	<20100114215839.GD32226@Space.Net> <87fx5x9g9y.fsf@mid.deneb.enyo.de>
	<4B5B4785.40505@titania.net>
Message-ID: <87my04v5ec.fsf@mid.deneb.enyo.de>

* Joseph T. Klein:

>> MX entries which point to a name lacking an A record cause relatively
>> widespread interoperability issues, due to sender domain verification
>> failures.

> Could this be a quad A reverse issue?

No, mail was rejected with 5xx errors by IPv4 mail servers.  There was
not even IPv6 involved in the failed SMTP transaction.

From brian.e.carpenter at gmail.com  Wed Jan 27 21:54:30 2010
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Thu, 28 Jan 2010 09:54:30 +1300
Subject: [Fwd: IPv6 deployment scenarios]
Message-ID: <4B60A806.7000807@gmail.com>

Please excuse the interruption if you've already seen this
or if you find it off-topic.

-------- Original Message --------
Subject: IPv6 deployment scenarios
Date: Fri, 22 Jan 2010 10:37:08 +1300
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
Organization: University of Auckland
To: nanog at nanog.org

Hi,

Sheng Jiang (Huawei) and Brian Carpenter (University of Auckland, research
consultant to Huawei) are currently running a questionnaire on IPv6 deployment,
addressed to every ISP. The purpose is to provide facts for a document about
deployment scenarios that we are drafting for discussion in the IETF.

We will keep your reply strictly confidential and we will publish only
combined results. We will not identify information about individual ISPs
in any published results. If you request it, we will not mention you or
the ISP in the acknowledgments.

Please find the questionnaire at
http://www.cs.auckland.ac.nz/~brian/ISP-v6-QQ.html
Answers are requested ASAP.

(Hmm. As I write, the IPv6 access to that server is broken.
Hopefully it will be back soon.)

btw, we know that the questionnaire is imperfect; all questionnaires
are imperfect. Also, this is not a marketing survey; we are after
technical information.

Regards
   Brian Carpenter



From martin at millnert.se  Fri Jan 29 00:51:58 2010
From: martin at millnert.se (Martin Millnert)
Date: Fri, 29 Jan 2010 00:51:58 +0100
Subject: Youtube-over-IPv6
Message-ID: <1264722718.1613.86.camel@hsa.vpn.anti>

Hello list,

thought you might want to know:

Google has quite recently enabled their Youtube content servers in the
Google over IPv6 program, http://www.google.com/intl/en/ipv6/ .

I do not want to steal their thunder, but this is great news everybody
should hear.

The effect of this is clearly visible in our IPv6 graphs at
http://stats.csbnet.se/public/ipv6/ , or more specifically
http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html

Regards,
-- 
Martin Millnert <martin at millnert.se>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100129/be78bcca/attachment.bin 

From ek at google.com  Fri Jan 29 01:45:35 2010
From: ek at google.com (Erik Kline)
Date: Fri, 29 Jan 2010 09:45:35 +0900
Subject: Youtube-over-IPv6
In-Reply-To: <1264722718.1613.86.camel@hsa.vpn.anti>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
Message-ID: <2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>

On 29 January 2010 08:51, Martin Millnert <martin at millnert.se> wrote:
> Hello list,
>
> thought you might want to know:
>
> Google has quite recently enabled their Youtube content servers in the
> Google over IPv6 program, http://www.google.com/intl/en/ipv6/ .
>
> I do not want to steal their thunder, but this is great news everybody
> should hear.
>
> The effect of this is clearly visible in our IPv6 graphs at
> http://stats.csbnet.se/public/ipv6/ , or more specifically
> http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html
>
> Regards,
> --
> Martin Millnert <martin at millnert.se>
>

I don't know yet if there will be a public announcement of some kind.
There may not be any thunder to steal.  =)

But hopefully it's working well and correctly.

From jimb at jsbc.cc  Fri Jan 29 02:57:06 2010
From: jimb at jsbc.cc (Jim Burwell)
Date: Thu, 28 Jan 2010 17:57:06 -0800
Subject: Youtube-over-IPv6
In-Reply-To: <2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
	<2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
Message-ID: <4B624072.3050408@jsbc.cc>

---8<---
On 1/28/2010 16:45, Erik Kline wrote:
>
> I don't know yet if there will be a public announcement of some kind.
> There may not be any thunder to steal.  =)
>
> But hopefully it's working well and correctly.
>   
Working well for me.  At this point it seems to just be the content
videos and not the web site itself.  When I play a video it comes
through my 6in4 tunnel now instead of the IPv4 path.  :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5570 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100128/05cbd195/attachment.bin 

From bwann-ipv6ops at wann.net  Fri Jan 29 07:17:43 2010
From: bwann-ipv6ops at wann.net (Bryan Wann)
Date: Fri, 29 Jan 2010 00:17:43 -0600 (CST)
Subject: Youtube-over-IPv6
In-Reply-To: <1264722718.1613.86.camel@hsa.vpn.anti>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
Message-ID: <alpine.LRH.2.00.1001290016130.32556@tifa.wann.net>

On Fri, 29 Jan 2010, Martin Millnert wrote:

> Google has quite recently enabled their Youtube content servers in the
> Google over IPv6 program, http://www.google.com/intl/en/ipv6/ .

Neat!  Any idea if there's a hostname that can be used for networks not in 
that program?


-- 
Met vriendelijke groet/kind regards,
bryan

From ek at google.com  Fri Jan 29 07:29:19 2010
From: ek at google.com (Erik Kline)
Date: Fri, 29 Jan 2010 15:29:19 +0900
Subject: Youtube-over-IPv6
In-Reply-To: <alpine.LRH.2.00.1001290016130.32556@tifa.wann.net>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
	<alpine.LRH.2.00.1001290016130.32556@tifa.wann.net>
Message-ID: <2e8c64261001282229o103898f9sc7b473223b5d5eaf@mail.gmail.com>

>> Google has quite recently enabled their Youtube content servers in the
>> Google over IPv6 program, http://www.google.com/intl/en/ipv6/ .
>
> Neat! ?Any idea if there's a hostname that can be used for networks not in
> that program?

No such thing is available at this time, sorry.

From s.ewing at aussiehq.com.au  Fri Jan 29 07:48:57 2010
From: s.ewing at aussiehq.com.au (Shaun Ewing)
Date: Fri, 29 Jan 2010 17:48:57 +1100
Subject: Youtube-over-IPv6
In-Reply-To: <2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
Message-ID: <C788D009.17205%s.ewing@aussiehq.com.au>



On 29/01/10 11:45 AM, "Erik Kline" <ek at google.com> wrote:

> But hopefully it's working well and correctly.

Good work, but there's a huge latency difference between v4 and v6 where I
am (Australia) and I seem to get v6 addresses out of a Google Ireland range
(2a00:1450::/32) from one set of our Google over V6 resolvers and the usual
Google range I'm used to (2001:4860::/32) from another set of our resolvers.

Despite that, there's no noticeable difference to user experience (ie:
videos seem to play fine) so I guess that's the key factor here.

Anyway, some info below if it's any use:

Our main resolvers use anycast within our network, but when using the ones
in my local city (CBR - which query from 203.88.112.0/24):

IPv4:

$ dig +short v21.lscache1.l.google.com A
74.125.109.30

--- 74.125.109.30 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.132/5.264/5.560/0.154 ms

And

traceroute to 74.125.109.30 (74.125.109.30), 64 hops max, 52 byte packets
 1  172.20.10.254 (172.20.10.254)  1.673 ms  1.064 ms  1.265 ms
 2  172.16.0.1 (172.16.0.1)  0.257 ms  0.164 ms  0.166 ms
 3  vl2.cor1.cbr1.as24557.net.au (203.88.112.252)  6.260 ms  9.195 ms  1.166
ms
 4  gi0-2-4.bdr2.cbr1.as24557.net.au (203.88.112.18)  0.582 ms  0.522 ms
0.468 ms
 5  gi0-2-4.bdr1.syd1.as24557.net.au (203.88.112.21)  5.492 ms  5.167 ms
5.044 ms
 6  as15169.sydney.pipenetworks.com (218.100.2.98)  5.106 ms  5.113 ms
5.287 ms
 7  64.233.174.253 (64.233.174.253)  5.515 ms  5.220 ms  5.738 ms
 8  74.125.109.30 (74.125.109.30)  5.210 ms  5.300 ms  5.384 ms

Vs

IPv6:

$ dig +short v21.lscache1.l.google.com AAAA
2a00:1450:4001:3::1e

--- 2a00:1450:4001:3::1e ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 351.175/354.353/355.477/1.600 ms

And

traceroute6 to 2a00:1450:4001:3::1e (2a00:1450:4001:3::1e) from
2405:5000:XX, 64 hops max, 12 byte packets
 1  2405:5000:XX  0.882 ms  0.766 ms  0.793 ms
 2  vl2-gw.cbr1.as24557.net.au  0.478 ms  0.389 ms  0.414 ms
 3  gi0-1-3.bdr2.cbr1.as24557.net.au  0.610 ms  0.541 ms  0.469 ms
 4  ge-0-0-0-700.bdr01.cbr01.act.vocus.net.au  0.714 ms  0.759 ms  0.699 ms
 5  2402:7800:0:2::35  4.757 ms  6.414 ms  4.866 ms
 6  ge-0-0-2.bdr02.syd01.nsw.vocus.net.au  4.922 ms  4.945 ms  4.758 ms
 7  2402:7800:0:2::3e  5.571 ms  11.963 ms  5.184 ms
 8  * * *
 9  * * *

And when querying our other set of resolvers in SYD (these query from
113.20.0.0/24):

IPv4:

$ dig +short v21.lscache1.l.google.com A
74.125.98.30

--- 74.125.98.30 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 276.145/276.523/277.288/0.451 ms

And

traceroute to 74.125.98.30 (74.125.98.30), 64 hops max, 52 byte packets
 1  172.20.10.254 (172.20.10.254)  1.834 ms  1.065 ms  1.072 ms
 2  172.16.0.1 (172.16.0.1)  0.245 ms  0.169 ms  0.182 ms
 3  vl2.cor1.cbr1.as24557.net.au (203.88.112.252)  0.732 ms  0.801 ms  0.733
ms
 4  gi0-2-4.bdr2.cbr1.as24557.net.au (203.88.112.18)  0.668 ms  0.563 ms
0.522 ms
 5  gi0-2-4.bdr1.syd1.as24557.net.au (203.88.112.21)  5.993 ms  4.816 ms
4.714 ms
 6  as15169.sydney.pipenetworks.com (218.100.2.97)  5.656 ms  6.546 ms
5.921 ms
 7  66.249.95.234 (66.249.95.234)  6.634 ms  5.372 ms  5.466 ms
 8  209.85.249.52 (209.85.249.52)  108.913 ms  105.382 ms  105.407 ms
 9  209.85.255.34 (209.85.255.34)  107.364 ms  134.131 ms  107.195 ms
10  72.14.232.114 (72.14.232.114)  176.733 ms  177.158 ms  175.981 ms
11  209.85.242.233 (209.85.242.233)  181.669 ms  181.570 ms  181.603 ms
12  66.249.94.39 (66.249.94.39)  219.298 ms  220.909 ms
    209.85.242.235 (209.85.242.235)  182.338 ms
13  209.85.241.53 (209.85.241.53)  276.365 ms  278.211 ms  276.176 ms
14  66.249.94.90 (66.249.94.90)  219.789 ms
    216.239.43.215 (216.239.43.215)  351.971 ms
    66.249.94.90 (66.249.94.90)  219.523 ms
15  * * *
16  74.125.98.30 (74.125.98.30)  276.886 ms
    216.239.43.215 (216.239.43.215)  277.086 ms
    74.125.98.30 (74.125.98.30)  276.653 ms

vs

IPv6:

$ dig +short v21.lscache1.l.google.com AAAA
2001:4860:4001:402::1e

--- 2001:4860:4001:402::1e ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 208.170/210.646/216.873/3.290 ms

And

traceroute6 to 2001:4860:4001:402::1e (2001:4860:4001:402::1e) from
2405:5000:XX, 64 hops max, 12 byte packets
 1  2405:5000:XX  1.301 ms  0.852 ms  1.014 ms
 2  vl2-gw.cbr1.as24557.net.au  0.582 ms  0.418 ms  0.464 ms
 3  gi0-1-3.bdr1.syd1.as24557.net.au  5.688 ms  5.097 ms  26.557 ms
 4  as15169.ipv6.sydney.pipenetworks.com  5.295 ms  8.224 ms  5.466 ms
 5  * * *
 6  * * *

:-)

-Shaun


From fahad.alikhan at gmail.com  Fri Jan 29 07:57:42 2010
From: fahad.alikhan at gmail.com (FAHAD ALI KHAN)
Date: Fri, 29 Jan 2010 11:57:42 +0500
Subject: Youtube-over-IPv6
In-Reply-To: <C788D009.17205%s.ewing@aussiehq.com.au>
References: <2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
	<C788D009.17205%s.ewing@aussiehq.com.au>
Message-ID: <9347ea5b1001282257w35ae7717w37f4b2775b5049bc@mail.gmail.com>

>From Pakistan, i observe the streaming through pure IPv4, not through v6 in
v4 tunnels.

Nor i find AAAA entries against www.youtube.com.

*Regards

Fahad Ali Khan*

On Fri, Jan 29, 2010 at 11:48 AM, Shaun Ewing <s.ewing at aussiehq.com.au>wrote:

>
>
> On 29/01/10 11:45 AM, "Erik Kline" <ek at google.com> wrote:
>
> > But hopefully it's working well and correctly.
>
> Good work, but there's a huge latency difference between v4 and v6 where I
> am (Australia) and I seem to get v6 addresses out of a Google Ireland range
> (2a00:1450::/32) from one set of our Google over V6 resolvers and the usual
> Google range I'm used to (2001:4860::/32) from another set of our
> resolvers.
>
> Despite that, there's no noticeable difference to user experience (ie:
> videos seem to play fine) so I guess that's the key factor here.
>
> Anyway, some info below if it's any use:
>
> Our main resolvers use anycast within our network, but when using the ones
> in my local city (CBR - which query from 203.88.112.0/24):
>
> IPv4:
>
> $ dig +short v21.lscache1.l.google.com A
> 74.125.109.30
>
> --- 74.125.109.30 ping statistics ---
> 5 packets transmitted, 5 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 5.132/5.264/5.560/0.154 ms
>
> And
>
> traceroute to 74.125.109.30 (74.125.109.30), 64 hops max, 52 byte packets
>  1  172.20.10.254 (172.20.10.254)  1.673 ms  1.064 ms  1.265 ms
>  2  172.16.0.1 (172.16.0.1)  0.257 ms  0.164 ms  0.166 ms
>  3  vl2.cor1.cbr1.as24557.net.au (203.88.112.252)  6.260 ms  9.195 ms
>  1.166
> ms
>  4  gi0-2-4.bdr2.cbr1.as24557.net.au (203.88.112.18)  0.582 ms  0.522 ms
> 0.468 ms
>  5  gi0-2-4.bdr1.syd1.as24557.net.au (203.88.112.21)  5.492 ms  5.167 ms
> 5.044 ms
>  6  as15169.sydney.pipenetworks.com (218.100.2.98)  5.106 ms  5.113 ms
> 5.287 ms
>  7  64.233.174.253 (64.233.174.253)  5.515 ms  5.220 ms  5.738 ms
>  8  74.125.109.30 (74.125.109.30)  5.210 ms  5.300 ms  5.384 ms
>
> Vs
>
> IPv6:
>
> $ dig +short v21.lscache1.l.google.com AAAA
> 2a00:1450:4001:3::1e
>
> --- 2a00:1450:4001:3::1e ping6 statistics ---
> 5 packets transmitted, 5 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 351.175/354.353/355.477/1.600 ms
>
> And
>
> traceroute6 to 2a00:1450:4001:3::1e (2a00:1450:4001:3::1e) from
> 2405:5000:XX, 64 hops max, 12 byte packets
>  1  2405:5000:XX  0.882 ms  0.766 ms  0.793 ms
>  2  vl2-gw.cbr1.as24557.net.au  0.478 ms  0.389 ms  0.414 ms
>  3  gi0-1-3.bdr2.cbr1.as24557.net.au  0.610 ms  0.541 ms  0.469 ms
>  4  ge-0-0-0-700.bdr01.cbr01.act.vocus.net.au  0.714 ms  0.759 ms  0.699
> ms
>  5  2402:7800:0:2::35  4.757 ms  6.414 ms  4.866 ms
>  6  ge-0-0-2.bdr02.syd01.nsw.vocus.net.au  4.922 ms  4.945 ms  4.758 ms
>  7  2402:7800:0:2::3e  5.571 ms  11.963 ms  5.184 ms
>  8  * * *
>  9  * * *
>
> And when querying our other set of resolvers in SYD (these query from
> 113.20.0.0/24):
>
> IPv4:
>
> $ dig +short v21.lscache1.l.google.com A
> 74.125.98.30
>
> --- 74.125.98.30 ping statistics ---
> 5 packets transmitted, 5 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 276.145/276.523/277.288/0.451 ms
>
> And
>
> traceroute to 74.125.98.30 (74.125.98.30), 64 hops max, 52 byte packets
>  1  172.20.10.254 (172.20.10.254)  1.834 ms  1.065 ms  1.072 ms
>  2  172.16.0.1 (172.16.0.1)  0.245 ms  0.169 ms  0.182 ms
>  3  vl2.cor1.cbr1.as24557.net.au (203.88.112.252)  0.732 ms  0.801 ms
>  0.733
> ms
>  4  gi0-2-4.bdr2.cbr1.as24557.net.au (203.88.112.18)  0.668 ms  0.563 ms
> 0.522 ms
>  5  gi0-2-4.bdr1.syd1.as24557.net.au (203.88.112.21)  5.993 ms  4.816 ms
> 4.714 ms
>  6  as15169.sydney.pipenetworks.com (218.100.2.97)  5.656 ms  6.546 ms
> 5.921 ms
>  7  66.249.95.234 (66.249.95.234)  6.634 ms  5.372 ms  5.466 ms
>  8  209.85.249.52 (209.85.249.52)  108.913 ms  105.382 ms  105.407 ms
>  9  209.85.255.34 (209.85.255.34)  107.364 ms  134.131 ms  107.195 ms
> 10  72.14.232.114 (72.14.232.114)  176.733 ms  177.158 ms  175.981 ms
> 11  209.85.242.233 (209.85.242.233)  181.669 ms  181.570 ms  181.603 ms
> 12  66.249.94.39 (66.249.94.39)  219.298 ms  220.909 ms
>    209.85.242.235 (209.85.242.235)  182.338 ms
> 13  209.85.241.53 (209.85.241.53)  276.365 ms  278.211 ms  276.176 ms
> 14  66.249.94.90 (66.249.94.90)  219.789 ms
>    216.239.43.215 (216.239.43.215)  351.971 ms
>    66.249.94.90 (66.249.94.90)  219.523 ms
> 15  * * *
> 16  74.125.98.30 (74.125.98.30)  276.886 ms
>    216.239.43.215 (216.239.43.215)  277.086 ms
>    74.125.98.30 (74.125.98.30)  276.653 ms
>
> vs
>
> IPv6:
>
> $ dig +short v21.lscache1.l.google.com AAAA
> 2001:4860:4001:402::1e
>
> --- 2001:4860:4001:402::1e ping6 statistics ---
> 5 packets transmitted, 5 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 208.170/210.646/216.873/3.290 ms
>
> And
>
> traceroute6 to 2001:4860:4001:402::1e (2001:4860:4001:402::1e) from
> 2405:5000:XX, 64 hops max, 12 byte packets
>  1  2405:5000:XX  1.301 ms  0.852 ms  1.014 ms
>  2  vl2-gw.cbr1.as24557.net.au  0.582 ms  0.418 ms  0.464 ms
>  3  gi0-1-3.bdr1.syd1.as24557.net.au  5.688 ms  5.097 ms  26.557 ms
>  4  as15169.ipv6.sydney.pipenetworks.com  5.295 ms  8.224 ms  5.466 ms
>  5  * * *
>  6  * * *
>
> :-)
>
> -Shaun
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100129/0608ff48/attachment-0001.html 

From gert at space.net  Fri Jan 29 09:11:35 2010
From: gert at space.net (Gert Doering)
Date: Fri, 29 Jan 2010 09:11:35 +0100
Subject: Youtube-over-IPv6
In-Reply-To: <2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
	<2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
Message-ID: <20100129081135.GJ32226@Space.Net>

Hi,

On Fri, Jan 29, 2010 at 09:45:35AM +0900, Erik Kline wrote:
> I don't know yet if there will be a public announcement of some kind.
> There may not be any thunder to steal.  =)
> 
> But hopefully it's working well and correctly.

I just tested, and it's working perfectly well - lots of happy packets, 
over native IPv6, and unless I look with tcpdump, no difference visible.

Great work!

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From danny at danysek.cz  Fri Jan 29 11:07:12 2010
From: danny at danysek.cz (Daniel Suchy)
Date: Fri, 29 Jan 2010 11:07:12 +0100
Subject: Youtube-over-IPv6
In-Reply-To: <20100129081135.GJ32226@Space.Net>
References: <1264722718.1613.86.camel@hsa.vpn.anti>	<2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
	<20100129081135.GJ32226@Space.Net>
Message-ID: <4B62B350.4050804@danysek.cz>

Hi,

even we participate in Google over IPv6 program, for YouTube DNS queries
we have only IPv4 addresses in the answers. Google works perfectly over
IPv6.

Isn't this limited for some region, for example? My actual observations
are from Czech Republic, checked from AS8251 & AS15685, both with same
result...

Daniel

On 01/29/2010 09:11 AM, Gert Doering wrote:
> Hi,
> 
> On Fri, Jan 29, 2010 at 09:45:35AM +0900, Erik Kline wrote:
>> I don't know yet if there will be a public announcement of some kind.
>> There may not be any thunder to steal.  =)
>>
>> But hopefully it's working well and correctly.
> 
> I just tested, and it's working perfectly well - lots of happy packets, 
> over native IPv6, and unless I look with tcpdump, no difference visible.
> 
> Great work!
> 
> Gert Doering
>         -- NetMaster

From gert at space.net  Fri Jan 29 11:10:27 2010
From: gert at space.net (Gert Doering)
Date: Fri, 29 Jan 2010 11:10:27 +0100
Subject: Youtube-over-IPv6
In-Reply-To: <4B62B350.4050804@danysek.cz>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
	<2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
	<20100129081135.GJ32226@Space.Net> <4B62B350.4050804@danysek.cz>
Message-ID: <20100129101027.GL32226@Space.Net>

Hi,

On Fri, Jan 29, 2010 at 11:07:12AM +0100, Daniel Suchy wrote:
> even we participate in Google over IPv6 program, for YouTube DNS queries
> we have only IPv4 addresses in the answers. Google works perfectly over
> IPv6.

The youtube web page is IPv4 only, but the images and videos are delivered
over IPv6.  You can see this in the dns on, for example, s.ytimg.com:

$ host s.ytimg.com
s.ytimg.com is a nickname for static.cache.l.google.com
static.cache.l.google.com has address 74.125.170.229
static.cache.l.google.com has address 2001:4860:4001:402::26

> Isn't this limited for some region, for example? My actual observations
> are from Czech Republic, checked from AS8251 & AS15685, both with same
> result...

I'm not sure - if you don't get v6 for images and videos either, it
might be that Google has decided "not enough v6 capacity near you".

For the web site, nobody gets v6 today - so that might be misleading.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

From danny at danysek.cz  Fri Jan 29 11:13:46 2010
From: danny at danysek.cz (Daniel Suchy)
Date: Fri, 29 Jan 2010 11:13:46 +0100
Subject: Youtube-over-IPv6
In-Reply-To: <20100129101027.GL32226@Space.Net>
References: <1264722718.1613.86.camel@hsa.vpn.anti>
	<2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com>
	<20100129081135.GJ32226@Space.Net> <4B62B350.4050804@danysek.cz>
	<20100129101027.GL32226@Space.Net>
Message-ID: <4B62B4DA.3010808@danysek.cz>

Hi,
thanks for amplification. We just checked youtube.com. I checked site
you mentioned and this works properly.

Daniel

On 01/29/2010 11:10 AM, Gert Doering wrote:
> Hi,
> 
> On Fri, Jan 29, 2010 at 11:07:12AM +0100, Daniel Suchy wrote:
>> even we participate in Google over IPv6 program, for YouTube DNS queries
>> we have only IPv4 addresses in the answers. Google works perfectly over
>> IPv6.
> 
> The youtube web page is IPv4 only, but the images and videos are delivered
> over IPv6.  You can see this in the dns on, for example, s.ytimg.com:
> 
> $ host s.ytimg.com
> s.ytimg.com is a nickname for static.cache.l.google.com
> static.cache.l.google.com has address 74.125.170.229
> static.cache.l.google.com has address 2001:4860:4001:402::26
> 
>> Isn't this limited for some region, for example? My actual observations
>> are from Czech Republic, checked from AS8251 & AS15685, both with same
>> result...
> 
> I'm not sure - if you don't get v6 for images and videos either, it
> might be that Google has decided "not enough v6 capacity near you".
> 
> For the web site, nobody gets v6 today - so that might be misleading.
> 
> Gert Doering
>         -- NetMaster

From nick-lists at netability.ie  Fri Jan 29 11:20:11 2010
From: nick-lists at netability.ie (Nick Hilliard)
Date: Fri, 29 Jan 2010 10:20:11 +0000
Subject: Youtube-over-IPv6
In-Reply-To: <C788D009.17205%s.ewing@aussiehq.com.au>
References: <C788D009.17205%s.ewing@aussiehq.com.au>
Message-ID: <4B62B65B.1010605@netability.ie>

On 29/01/2010 06:48, Shaun Ewing wrote:
> Good work, but there's a huge latency difference between v4 and v6 where I
> am (Australia) and I seem to get v6 addresses out of a Google Ireland range
> (2a00:1450::/32) 

although Google Ireland is the LIR, it looks like the content is being
served out of Amsterdam (judging entirely by the latency from Dublin).

Nick

From tedm at ipinc.net  Sat Jan 30 02:35:45 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 29 Jan 2010 17:35:45 -0800
Subject: Noticed IPv6 in a switch today
Message-ID: <4B638CF1.2040209@ipinc.net>

Hi All,

   Apologies if this is old news to anyone but I noticed
today after completing a firmware update on a Netgear GS724TS
that it now appears to have IPv6 filtering capability.  I
don't recall seeing it in the switch interface before.

    I thought it was interesting as it's the first "lower-end,
non-enterprise" ethernet switch I've seen that even mentioned IPv6

Ted

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Sat Jan 30 02:40:49 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Sat, 30 Jan 2010 12:10:49 +1030
Subject: Noticed IPv6 in a switch today
In-Reply-To: <4B638CF1.2040209@ipinc.net>
References: <4B638CF1.2040209@ipinc.net>
Message-ID: <20100130121049.0c65a60b@opy.nosense.org>

On Fri, 29 Jan 2010 17:35:45 -0800
Ted Mittelstaedt <tedm at ipinc.net> wrote:

> Hi All,
> 
>    Apologies if this is old news to anyone but I noticed
> today after completing a firmware update on a Netgear GS724TS
> that it now appears to have IPv6 filtering capability.  I
> don't recall seeing it in the switch interface before.
> 

Does it look to have any other IPv6 oriented features, e.g. MLD
snooping, SAVI? What level of filtering does it have?

>     I thought it was interesting as it's the first "lower-end,
> non-enterprise" ethernet switch I've seen that even mentioned IPv6
> 
> Ted

From nuno.vieira at nfsi.pt  Sat Jan 30 10:39:39 2010
From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom)
Date: Sat, 30 Jan 2010 09:39:39 +0000 (WET)
Subject: Noticed IPv6 in a switch today
In-Reply-To: <4B638CF1.2040209@ipinc.net>
Message-ID: <1809422201.7810.1264844379798.JavaMail.root@zimbra.nfsi.pt>

Hi Ted,

Some SMC switches have few IPv6 features aswell for some time...

regards,
--nvieira


----- "Ted Mittelstaedt" <tedm at ipinc.net> wrote:

> Hi All,
> 
>    Apologies if this is old news to anyone but I noticed
> today after completing a firmware update on a Netgear GS724TS
> that it now appears to have IPv6 filtering capability.  I
> don't recall seeing it in the switch interface before.
> 
>     I thought it was interesting as it's the first "lower-end,
> non-enterprise" ethernet switch I've seen that even mentioned IPv6
> 
> Ted

From tedm at ipinc.net  Sun Jan 31 05:17:39 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Sat, 30 Jan 2010 20:17:39 -0800
Subject: Noticed IPv6 in a switch today
In-Reply-To: <20100130121049.0c65a60b@opy.nosense.org>
References: <4B638CF1.2040209@ipinc.net>
	<20100130121049.0c65a60b@opy.nosense.org>
Message-ID: <4B650463.2070107@ipinc.net>

Mark Smith wrote:
> On Fri, 29 Jan 2010 17:35:45 -0800
> Ted Mittelstaedt <tedm at ipinc.net> wrote:
> 
>> Hi All,
>>
>>    Apologies if this is old news to anyone but I noticed
>> today after completing a firmware update on a Netgear GS724TS
>> that it now appears to have IPv6 filtering capability.  I
>> don't recall seeing it in the switch interface before.
>>
> 
> Does it look to have any other IPv6 oriented features, e.g. MLD
> snooping, SAVI? What level of filtering does it have?
> 

I'll post a link to a screen shot in a few days.

Ted

>>     I thought it was interesting as it's the first "lower-end,
>> non-enterprise" ethernet switch I've seen that even mentioned IPv6
>>
>> Ted


From merike at doubleshotsecurity.com  Sun Jan 31 05:37:32 2010
From: merike at doubleshotsecurity.com (Merike Kaeo)
Date: Sat, 30 Jan 2010 20:37:32 -0800
Subject: Noticed IPv6 in a switch today
In-Reply-To: <4B650463.2070107@ipinc.net>
References: <4B638CF1.2040209@ipinc.net>
	<20100130121049.0c65a60b@opy.nosense.org>
	<4B650463.2070107@ipinc.net>
Message-ID: <42ECB4A4-2013-40DC-B2D6-C941E6D38E92@doubleshotsecurity.com>

Just an added question below...

On Jan 30, 2010, at 8:17 PM, Ted Mittelstaedt wrote:

> Mark Smith wrote:
>> On Fri, 29 Jan 2010 17:35:45 -0800
>> Ted Mittelstaedt <tedm at ipinc.net> wrote:
>>> Hi All,
>>>
>>>    Apologies if this is old news to anyone but I noticed
>>> today after completing a firmware update on a Netgear GS724TS
>>> that it now appears to have IPv6 filtering capability.  I
>>> don't recall seeing it in the switch interface before.
>>>
>> Does it look to have any other IPv6 oriented features, e.g. MLD
>> snooping, SAVI? What level of filtering does it have?
>
> I'll post a link to a screen shot in a few days.

I'd also be curious to know whether they log filter exceptions.  A  
few years back I was short of stunned that devices that did some  
rudimentary IPv6 filtering did not have the capability to log any  
exceptions.  But yay for more vendors starting to recognize that v6  
really is going to happen...

- merike

From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org  Sun Jan 31 05:50:39 2010
From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
Date: Sun, 31 Jan 2010 15:20:39 +1030
Subject: Noticed IPv6 in a switch today
In-Reply-To: <4B650463.2070107@ipinc.net>
References: <4B638CF1.2040209@ipinc.net>
	<20100130121049.0c65a60b@opy.nosense.org>
	<4B650463.2070107@ipinc.net>
Message-ID: <20100131152039.150aca59@opy.nosense.org>

On Sat, 30 Jan 2010 20:17:39 -0800
Ted Mittelstaedt <tedm at ipinc.net> wrote:

> Mark Smith wrote:
> > On Fri, 29 Jan 2010 17:35:45 -0800
> > Ted Mittelstaedt <tedm at ipinc.net> wrote:
> > 
> >> Hi All,
> >>
> >>    Apologies if this is old news to anyone but I noticed
> >> today after completing a firmware update on a Netgear GS724TS
> >> that it now appears to have IPv6 filtering capability.  I
> >> don't recall seeing it in the switch interface before.
> >>
> > 
> > Does it look to have any other IPv6 oriented features, e.g. MLD
> > snooping, SAVI? What level of filtering does it have?
> > 
> 
> I'll post a link to a screen shot in a few days.
> 

Ok, thanks.

> Ted
> 
> >>     I thought it was interesting as it's the first "lower-end,
> >> non-enterprise" ethernet switch I've seen that even mentioned IPv6
> >>
> >> Ted
>