From tore.anderson at redpill-linpro.com  Tue Dec  1 09:22:38 2009
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Tue, 01 Dec 2009 09:22:38 +0100
Subject: IPv6 brokenness experiment, November results
Message-ID: <4B14D24E.6050707@redpill-linpro.com>

Hi all,

thought I'd share with you the results from my experiment for November
like I did for October a month ago (for more details, see
http://thread.gmane.org/gmane.org.operators.ipv6/2636).  The 3rd of
November I removed the split-horizon DNS stuff that blacklisted a couple
of eyeball networks known to be broken for 6to4 from seeing AAAA
responses, other than that the experiment has been running unmodified.

Opera is still by far the biggest cause of breakage - about nine out of
ten clients that are unable to access the dualstack site appears to be
Opera users with (presumably) broken 6to4 or Teredo connectivity.  Three
weeks ago they told me that the issue was beeing looked into, but no
word yet on whether a fix is forthcoming or not.

The raw numbers are attached.

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: 200911.txt
Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/a27ebb63/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 200911-noopera.txt
Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/a27ebb63/attachment-0001.txt 

From chaz at chaz6.com  Tue Dec  1 11:50:01 2009
From: chaz at chaz6.com (Chris Hills)
Date: Tue, 01 Dec 2009 11:50:01 +0100
Subject: IPv6 brokenness experiment, November results
In-Reply-To: <4B14D24E.6050707@redpill-linpro.com>
References: <4B14D24E.6050707@redpill-linpro.com>
Message-ID: <hf2scu$dj1$1@ger.gmane.org>

On 01/12/09 09:22, Tore Anderson wrote:
> Opera is still by far the biggest cause of breakage - about nine out of
> ten clients that are unable to access the dualstack site appears to be
> Opera users with (presumably) broken 6to4 or Teredo connectivity.  Three
> weeks ago they told me that the issue was beeing looked into, but no
> word yet on whether a fix is forthcoming or not.

I recently updated Opera to 10.10-4742 on Linux x86 (qt4 shared) and it
now seems to prefer ipv4 when both ipv4 and ipv6 are available for the
website, from a host with global unicast addresses.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/2b548c5d/attachment.bin 

From ek at google.com  Tue Dec  1 15:09:23 2009
From: ek at google.com (Erik Kline)
Date: Tue, 1 Dec 2009 06:09:23 -0800
Subject: IPv6 brokenness experiment, November results
In-Reply-To: <hf2scu$dj1$1@ger.gmane.org>
References: <4B14D24E.6050707@redpill-linpro.com> <hf2scu$dj1$1@ger.gmane.org>
Message-ID: <2e8c64260912010609p531787b2x3558f1883584e6e4@mail.gmail.com>

2009/12/1 Chris Hills <chaz at chaz6.com>:
> On 01/12/09 09:22, Tore Anderson wrote:
>> Opera is still by far the biggest cause of breakage - about nine out of
>> ten clients that are unable to access the dualstack site appears to be
>> Opera users with (presumably) broken 6to4 or Teredo connectivity. ?Three
>> weeks ago they told me that the issue was beeing looked into, but no
>> word yet on whether a fix is forthcoming or not.
>
> I recently updated Opera to 10.10-4742 on Linux x86 (qt4 shared) and it
> now seems to prefer ipv4 when both ipv4 and ipv6 are available for the
> website, from a host with global unicast addresses.

Hmmm...somehow that doesn't quite seem like the right fix.  In a
dualstacked but heavily v4-NAT'd world it would still prefer v4?

From alexander.mayrhofer at nic.at  Tue Dec  1 15:42:52 2009
From: alexander.mayrhofer at nic.at (Alexander Mayrhofer)
Date: Tue, 1 Dec 2009 15:42:52 +0100
Subject: SSL over IPv6 broken in Firefox for Windows...
Message-ID: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>

Hello,

A colleague of mine has recently found out that the popular Firefox web
browser fails on https-URLs over IPv6, but only on Windows (Linux works
fine). The only way to get https sites working is to disable IPv6 in the
browser - not very useful for fostering IPv6 deployment. The full bug
report is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=513659

I think this is a major issues - however, i do understand that the focus
of the Mozilla developers is not necessarily on IPv6 yet. However, feel
free to vote for the bug if you think that it deserves more attention ;)

Thanks,

Alex

From tore.anderson at redpill-linpro.com  Tue Dec  1 15:50:52 2009
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Tue, 01 Dec 2009 15:50:52 +0100
Subject: IPv6 brokenness experiment, November results
In-Reply-To: <hf2scu$dj1$1@ger.gmane.org>
References: <4B14D24E.6050707@redpill-linpro.com> <hf2scu$dj1$1@ger.gmane.org>
Message-ID: <4B152D4C.5000000@redpill-linpro.com>

* Chris Hills

> I recently updated Opera to 10.10-4742 on Linux x86 (qt4 shared) and
> it now seems to prefer ipv4 when both ipv4 and ipv6 are available for
> the website, from a host with global unicast addresses.

Unfortunately that won't make much of a difference, as no major Linux
distribution that I know of set up 6to4 or Teredo out of the box.

It is the Windows users who are affected the most by Opera's
misbehaviour, due to the fact that Vista and newer will automatically
set up Teredo and 6to4 tunnels.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From martin at hotze.com  Tue Dec  1 15:52:13 2009
From: martin at hotze.com (Martin Hotze)
Date: Tue, 1 Dec 2009 15:52:13 +0100
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
Message-ID: <275E689A52D3FD4E922743D02EAEA8FA2C2623@server1.hotze.local>

Also,

https://www.makhutov.org/ funktioniert hier mit IPv6, WinXP, FF 3.5.5
- es ist ein CAcert und ich habe das Root-Zertifikat im Browser
installiert.


https://timatio.com/ bringt einen Fehler: "SSL hat einen Eintrag
erhalten, der die maximal erlaubte L?nge ?berschritten hat.
(Fehlercode: ssl_error_rx_record_too_long)"

Lg, Martin

> -----Original Message-----
> From: ipv6-ops-bounces+martin=hotze.com at lists.cluenet.de
[mailto:ipv6-ops-
> bounces+martin=hotze.com at lists.cluenet.de] On Behalf Of Alexander
> Mayrhofer
> Sent: Tuesday, December 01, 2009 3:43 PM
> To: ipv6-ops at lists.cluenet.de
> Subject: SSL over IPv6 broken in Firefox for Windows...
> 
> Hello,
> 
> A colleague of mine has recently found out that the popular Firefox
web
> browser fails on https-URLs over IPv6, but only on Windows (Linux
works
> fine). The only way to get https sites working is to disable IPv6 in
the
> browser - not very useful for fostering IPv6 deployment. The full
bug
> report is here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=513659
> 
> I think this is a major issues - however, i do understand that the
focus
> of the Mozilla developers is not necessarily on IPv6 yet. However,
feel
> free to vote for the bug if you think that it deserves more
attention ;)
> 
> Thanks,
> 
> Alex

From shane at time-travellers.org  Tue Dec  1 16:09:58 2009
From: shane at time-travellers.org (Shane Kerr)
Date: Tue, 01 Dec 2009 16:09:58 +0100
Subject: ShowIP
In-Reply-To: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
Message-ID: <1259680198.25941.88.camel@shane-asus-laptop>

All,

The mail about the Mozilla IPv6 SSL brokenness reminded me that I'd been
meaning to pimp a Firefox plugin that I like:

http://code.google.com/p/firefox-showip/

It shows the IP address used to connect to a sight in the lower corner
of your browser. Nice for knowing how IPv6-enabled your daily browsing
is.

Cheers,

--
Shane


From jeroen at unfix.org  Tue Dec  1 16:43:12 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 01 Dec 2009 16:43:12 +0100
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
Message-ID: <4B153990.2020301@spaghetti.zurich.ibm.com>

Alexander Mayrhofer wrote:
> Hello,
> 
> A colleague of mine has recently found out that the popular Firefox web
> browser fails on https-URLs over IPv6, but only on Windows (Linux works
> fine). The only way to get https sites working is to disable IPv6 in the
> browser - not very useful for fostering IPv6 deployment. The full bug
> report is here:

Strange.... I use IPv6+SSL every day with Firefox on Windows XP, and it
works like a charm...

I think I've been going to https://www.sixxs.net/ for at least 8 years
now and that with Firefox on Windows...

Tracepath6 tells me:

 8:  deham01.sixxs.net                         20.776ms asymm  7
 9:  deham01.sixxs.net                         20.700ms pmtu 1480
 9:  bane.makhutov-it.de                       37.214ms reached
 9:  bane.makhutov-it.de                       37.520ms reached

I would not be surprised that somebody has an MTU issue somewhere...
1480 is definitely not the standard for tunnels and might also be a
problem in other places. Check all your settings(tm).

Timatio also ends in:

 8:  2a01:190:1701::12                         28.616ms asymm  9
 9:  2a01:190:1701::12                         28.568ms pmtu 1480
 9:  2a02:850:3:3::9327                        49.000ms reached
 9:  2a02:850:3:3::9327                        49.082ms reached
     Resume: pmtu 1480 hops 9 back 55


Might I suggest checking https://www.sixxs.net or https://unfix.org ? :)
(requires CACert or just click 'accept' ;)

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/c40b1e36/attachment.bin 

From jeroen at unfix.org  Tue Dec  1 16:44:42 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 01 Dec 2009 16:44:42 +0100
Subject: ShowIP
In-Reply-To: <1259680198.25941.88.camel@shane-asus-laptop>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<1259680198.25941.88.camel@shane-asus-laptop>
Message-ID: <4B1539EA.7030707@spaghetti.zurich.ibm.com>

Shane Kerr wrote:
> All,
> 
> The mail about the Mozilla IPv6 SSL brokenness reminded me that I'd been
> meaning to pimp a Firefox plugin that I like:
> 
> http://code.google.com/p/firefox-showip/
> 
> It shows the IP address used to connect to a sight in the lower corner
> of your browser. Nice for knowing how IPv6-enabled your daily browsing
> is.

And unfortunately quite useless. All it does is a AAAA DNS lookup and
then shows that if an IPv6 address exists in DNS, wether that is used
for connecting or not....

Also note that the tool doesn't cope in any way with multiple IPv6 and
IPv4 addresses.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/9aee1913/attachment.bin 

From swmike at swm.pp.se  Tue Dec  1 16:50:45 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 1 Dec 2009 16:50:45 +0100 (CET)
Subject: ShowIP
In-Reply-To: <1259680198.25941.88.camel@shane-asus-laptop>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<1259680198.25941.88.camel@shane-asus-laptop>
Message-ID: <alpine.DEB.1.10.0912011644510.23464@uplift.swm.pp.se>

On Tue, 1 Dec 2009, Shane Kerr wrote:

> It shows the IP address used to connect to a sight in the lower corner
> of your browser. Nice for knowing how IPv6-enabled your daily browsing
> is.

It actually doesn't know, it *GUESSES* what IP will be used, and shows 
that one.

It doesn't actually show what IPv4/IPv6 address the TCP connection really 
goes to (I just routed my web server IPv6 address to somewhere that didn't 
work and dumped the traffic, the actual webpage was fetched over IPv4 even 
though ShowIP indicated it was using IPv6).

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

From alexander.mayrhofer at nic.at  Tue Dec  1 16:53:37 2009
From: alexander.mayrhofer at nic.at (Alexander Mayrhofer)
Date: Tue, 1 Dec 2009 16:53:37 +0100
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <4B153990.2020301@spaghetti.zurich.ibm.com>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<4B153990.2020301@spaghetti.zurich.ibm.com>
Message-ID: <8BC845943058D844ABFC73D2220D466508C0031E@nics-mail.sbg.nic.at>

 

> Strange.... I use IPv6+SSL every day with Firefox on Windows 
> XP, and it
> works like a charm...
> 
> I think I've been going to https://www.sixxs.net/ for at least 8 years
> now and that with Firefox on Windows...

[...]

> Might I suggest checking https://www.sixxs.net or 
> https://unfix.org ? :)
> (requires CACert or just click 'accept' ;)

Both don't work for me - same behaviour as described in the mozilla bug.
I'll try from a different network, just to ensure it has nothing to do
with any of the components here... (no web proxy, no NAT... Hmmm...
Weird..)

Alex

From hahn at berkom.de  Tue Dec  1 16:53:32 2009
From: hahn at berkom.de (Christian Hahn)
Date: Tue, 01 Dec 2009 16:53:32 +0100
Subject: issue with SLAAC and deprecated IPv6 addresses on recent windows
	versions
Message-ID: <4B153BFC.4040204@berkom.de>

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

Hi list,

In a lab I did some testing with SLAAC and different OSs and recently stumbled
upon an issue on recent windows versions. It is only present on Vista and 7, not
on XP. But let me tell you the story ...

I deprecated an formerly (by RA) announced IPv6 prefix (let's say
2001:db8:1:2::/64) by  sending some RAs with PreferredLifetime=0 and
ValidLifetime=7200 and thereafter stopped sending RAs.
All windows machines behaved correctly and deprecated the addresses derived from
that prefix. Outgoing connections no longer used it as source address, but
incoming packets (like icmpv6 echo request) where answered due to the valid
"ValidLifetime" value. ;)

Then in the second step (after some minutes of testing) I tried to re-activate
the _same_ prefix (2001:db8:1:2::/64) by sending periodic RAs with
PreferredLifetime=86400 and ValidLifetime=43200. And here the weird things
began. On Vista and 7 the values for the "Lifetimes" where updated to the new
ones derived from the RA, but the prefix status didn't change. It still was
stuck in status "deprecated". Hence the still valid IPv6 addresses from that
prefix (2001:db8:1:2::/64) wasn't used as source addresses for new connections,
only old connections used it and incoming packets where answered.

On XP it was different. The prefix came back to life, changed to status
"preferred" and the system again used it's 2001:db8:1:2::/64 IPv6 addresses as
source address for new connections.

To proof it I replicated the test, and restarted all machines beforehand. But
the result didn't change, hence it seems it is "stable" behavior.

I assume it's not the proper behavior, but found no clue in RFC4862 (SLAAC)
where I was looking for allowed status changes or similar.
Has anybody seen a similar behavior or made similar tests with different results?

BTW. I used radvd 1.1 on Ubuntu 9.04 on the router side.

cheers,
Christian
- ------------------
gpg fingerprint:
31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAksVO/oACgkQ6kMW7HW86231ZwCdHIoyTIMPl7gVqFrtsrKSpRdZ
MfQAn3z/pV04RMw1OVSNrzz4d5028pdl
=26n8
-----END PGP SIGNATURE-----

From jeroen at unfix.org  Tue Dec  1 16:58:46 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 01 Dec 2009 16:58:46 +0100
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <8BC845943058D844ABFC73D2220D466508C0031E@nics-mail.sbg.nic.at>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<4B153990.2020301@spaghetti.zurich.ibm.com>
	<8BC845943058D844ABFC73D2220D466508C0031E@nics-mail.sbg.nic.at>
Message-ID: <4B153D36.60701@spaghetti.zurich.ibm.com>

Alexander Mayrhofer wrote:
[..]
>> Might I suggest checking https://www.sixxs.net or 
>> https://unfix.org ? :)
>> (requires CACert or just click 'accept' ;)
> 
> Both don't work for me - same behaviour as described in the mozilla bug.
> I'll try from a different network, just to ensure it has nothing to do
> with any of the components here... (no web proxy, no NAT... Hmmm...
> Weird..)

Don't forget the option: No Stupid Firewalling software....

Too many "firewalls" simply don't understand IPv6 and thus just either
drop all IPv6 packets (thus causing 20second+ timeouts) or at least
reject them, which would look like what you see in your wireshark.

As such: install Windows Defender, go to "Tools" -> "Software Explorer"
-> "Winsock Service Providers" and see what junk is there to hijack any
Winsock (and thus IPv4+IPv6) connections.

And of course you might also just want to check that you actually have
proper IPv6 connectivity.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/67d19086/attachment-0001.bin 

From ryanczak at arin.net  Tue Dec  1 17:00:07 2009
From: ryanczak at arin.net (Matt Ryanczak)
Date: Tue, 01 Dec 2009 11:00:07 -0500
Subject: ShowIP
In-Reply-To: <alpine.DEB.1.10.0912011644510.23464@uplift.swm.pp.se>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<1259680198.25941.88.camel@shane-asus-laptop>
	<alpine.DEB.1.10.0912011644510.23464@uplift.swm.pp.se>
Message-ID: <1259683207.3121.60.camel@otto>

On Tue, 2009-12-01 at 10:50 -0500, Mikael Abrahamsson wrote:
> On Tue, 1 Dec 2009, Shane Kerr wrote:
> 
> > It shows the IP address used to connect to a sight in the lower corner
> > of your browser. Nice for knowing how IPv6-enabled your daily browsing
> > is.
> 
> It actually doesn't know, it *GUESSES* what IP will be used, and shows 
> that one.
> 

This is still useful behavior. Having been on IPv6 for quite sometime
now I have found this tool useful for determining why I can't connect to
a certain website. If I see an IPv6 address in the status bar when
loading a website fails I know what to check first...

~Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/84531a40/attachment.bin 

From alexander.mayrhofer at nic.at  Tue Dec  1 17:10:29 2009
From: alexander.mayrhofer at nic.at (Alexander Mayrhofer)
Date: Tue, 1 Dec 2009 17:10:29 +0100
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <4B153D36.60701@spaghetti.zurich.ibm.com>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<4B153990.2020301@spaghetti.zurich.ibm.com>
	<8BC845943058D844ABFC73D2220D466508C0031E@nics-mail.sbg.nic.at>
	<4B153D36.60701@spaghetti.zurich.ibm.com>
Message-ID: <8BC845943058D844ABFC73D2220D466508C00325@nics-mail.sbg.nic.at>

 

> Don't forget the option: No Stupid Firewalling software....
> 
> Too many "firewalls" simply don't understand IPv6 and thus just either
> drop all IPv6 packets (thus causing 20second+ timeouts) or at least
> reject them, which would look like what you see in your wireshark.

Reject, specific to a certain browser? ;) Will doublecheck anyway.

> As such: install Windows Defender, go to "Tools" -> "Software 
> Explorer"
> -> "Winsock Service Providers" and see what junk is there to 
> hijack any
> Winsock (and thus IPv4+IPv6) connections.
> 
> And of course you might also just want to check that you actually have
> proper IPv6 connectivity.

Well, all that doesn't explain why 

A) plain HTTP connections over v6 work like a charm, even with Firefox
B) plain HTTP as well as HTTPS connections work like a charm with
Internet Explorer and Opera
C) almost all our management traffic (ssh) and other application traffic
to our servers (smtp, imap) works perfectly well. That's native dual
stack connectivity, no tunnels involved. 

But, i'll doublecheck all options...

Thanks,

Alex

From jeroen at unfix.org  Tue Dec  1 17:14:09 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 01 Dec 2009 17:14:09 +0100
Subject: ShowIP
In-Reply-To: <1259683207.3121.60.camel@otto>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>	<1259680198.25941.88.camel@shane-asus-laptop>	<alpine.DEB.1.10.0912011644510.23464@uplift.swm.pp.se>
	<1259683207.3121.60.camel@otto>
Message-ID: <4B1540D1.9080304@spaghetti.zurich.ibm.com>

Matt Ryanczak wrote:
> On Tue, 2009-12-01 at 10:50 -0500, Mikael Abrahamsson wrote:
>> On Tue, 1 Dec 2009, Shane Kerr wrote:
>>
>>> It shows the IP address used to connect to a sight in the lower corner
>>> of your browser. Nice for knowing how IPv6-enabled your daily browsing
>>> is.
>> It actually doesn't know, it *GUESSES* what IP will be used, and shows 
>> that one.
>>
> 
> This is still useful behavior. Having been on IPv6 for quite sometime
> now I have found this tool useful for determining why I can't connect to
> a certain website. If I see an IPv6 address in the status bar when
> loading a website fails I know what to check first...

What to check first: tracepath6 + tracepath <hostname> ....

Then apply wireshark where needed (or firebug for that matter)

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091201/dfe23ee6/attachment.bin 

From dwing at cisco.com  Tue Dec  1 18:04:24 2009
From: dwing at cisco.com (Dan Wing)
Date: Tue, 1 Dec 2009 09:04:24 -0800
Subject: IPv6 brokenness experiment, November results
In-Reply-To: <2e8c64260912010609p531787b2x3558f1883584e6e4@mail.gmail.com>
References: <4B14D24E.6050707@redpill-linpro.com> <hf2scu$dj1$1@ger.gmane.org>
	<2e8c64260912010609p531787b2x3558f1883584e6e4@mail.gmail.com>
Message-ID: <094301ca72a8$55c58280$c3f0200a@cisco.com>

> -----Original Message-----
> From: ipv6-ops-bounces+dwing=cisco.com at lists.cluenet.de 
> [mailto:ipv6-ops-bounces+dwing=cisco.com at lists.cluenet.de] On 
> Behalf Of Erik Kline
> Sent: Tuesday, December 01, 2009 6:09 AM
> To: Chris Hills
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: IPv6 brokenness experiment, November results
> 
> 2009/12/1 Chris Hills <chaz at chaz6.com>:
> > On 01/12/09 09:22, Tore Anderson wrote:
> >> Opera is still by far the biggest cause of breakage - 
> about nine out of
> >> ten clients that are unable to access the dualstack site 
> appears to be
> >> Opera users with (presumably) broken 6to4 or Teredo 
> connectivity. ?Three
> >> weeks ago they told me that the issue was beeing looked 
> into, but no
> >> word yet on whether a fix is forthcoming or not.
> >
> > I recently updated Opera to 10.10-4742 on Linux x86 (qt4 
> shared) and it
> > now seems to prefer ipv4 when both ipv4 and ipv6 are 
> available for the
> > website, from a host with global unicast addresses.
> 
> Hmmm...somehow that doesn't quite seem like the right fix.  In a
> dualstacked but heavily v4-NAT'd world it would still prefer v4?

I agree the new Opera behavior is not desirable.

We wrote Happy Eyeballs to encourage quicker response to IPv6
breakage (such as dead tunnels) or to IPv4 breakage (such as
exhausted TCP ports), so that users are effectively unaware
of the browser preferring IPv4 over IPv6 (during the morning) 
or preferring IPv6 over IPv4 (during the afternoon),
http://tools.ietf.org/html/draft-wing-http-new-tech-00

-d


From swmike at swm.pp.se  Tue Dec  1 19:04:28 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 1 Dec 2009 19:04:28 +0100 (CET)
Subject: ShowIP
In-Reply-To: <1259683207.3121.60.camel@otto>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<1259680198.25941.88.camel@shane-asus-laptop>
	<alpine.DEB.1.10.0912011644510.23464@uplift.swm.pp.se>
	<1259683207.3121.60.camel@otto>
Message-ID: <alpine.DEB.1.10.0912011901510.23464@uplift.swm.pp.se>

On Tue, 1 Dec 2009, Matt Ryanczak wrote:

> This is still useful behavior. Having been on IPv6 for quite sometime 
> now I have found this tool useful for determining why I can't connect to 
> a certain website. If I see an IPv6 address in the status bar when 
> loading a website fails I know what to check first...

Yes, it's useful, but one has to understand what it really does to 
understand what's going on. Saying "It shows the IP address used to 
connect" (as was stated in the initial post) is just not true. Well, per 
some definition it might be, if one implies "the first IP used", if this 
connection attempt fails then the webpage might very well be loaded from 
sone other IP (as was in my example).

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

From dougb at dougbarton.us  Tue Dec  1 19:15:16 2009
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 01 Dec 2009 10:15:16 -0800
Subject: ShowIP
In-Reply-To: <alpine.DEB.1.10.0912011901510.23464@uplift.swm.pp.se>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>	<1259680198.25941.88.camel@shane-asus-laptop>	<alpine.DEB.1.10.0912011644510.23464@uplift.swm.pp.se>	<1259683207.3121.60.camel@otto>
	<alpine.DEB.1.10.0912011901510.23464@uplift.swm.pp.se>
Message-ID: <4B155D34.5080501@dougbarton.us>

Mikael Abrahamsson wrote:
> On Tue, 1 Dec 2009, Matt Ryanczak wrote:
> 
>> This is still useful behavior. Having been on IPv6 for quite sometime
>> now I have found this tool useful for determining why I can't connect
>> to a certain website. If I see an IPv6 address in the status bar when
>> loading a website fails I know what to check first...
> 
> Yes, it's useful, but one has to understand what it really does to
> understand what's going on. Saying "It shows the IP address used to
> connect" (as was stated in the initial post) is just not true. 

Wow, tough room! In fairness to the OP the description of the plugin
(which I have also used for some time and like) does seem to indicate
that it is showing the IP address used to connect. I became suspicious
about that one day when I had my IPv6 off for testing and the plugin
was still showing IPv6. :)


Doug

-- 

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


From Scott.Beuker at sjrb.ca  Tue Dec  1 22:05:46 2009
From: Scott.Beuker at sjrb.ca (Scott Beuker)
Date: Tue, 1 Dec 2009 14:05:46 -0700
Subject: issue with SLAAC and deprecated IPv6 addresses on recent
	windowsversions
In-Reply-To: <4B153BFC.4040204@berkom.de>
References: <4B153BFC.4040204@berkom.de>
Message-ID: <46A2DD1223D7BF47B61799AFFBA8AD8907A93D72@PRDCG4EXVW01-1.OSS.PRD>

Interesting bug, nice job in finding it.

I was talking to a friend who works at MS about what (if any) viable
avenues there are to report a bug like this and actually stand a chance
of getting it resolved. He recommend this:

http://connect.microsoft.com/WNDP/Feedback

I have no idea how much mileage you would get down this avenue, but if
you're feeling optimistic give it a shot, and let me know and I'll be
sure to create an account just to vote your bug up. :)

Thanks,
Scott



> -----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 Christian Hahn
> Sent: Tuesday, December 01, 2009 8:54 AM
> To: IPv6 Ops list
> Subject: issue with SLAAC and deprecated IPv6 addresses on recent
> windowsversions
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi list,
> 
> In a lab I did some testing with SLAAC and different OSs and recently
> stumbled
> upon an issue on recent windows versions. It is only present on Vista
> and 7, not
> on XP. But let me tell you the story ...
> 
> I deprecated an formerly (by RA) announced IPv6 prefix (let's say
> 2001:db8:1:2::/64) by  sending some RAs with PreferredLifetime=0 and
> ValidLifetime=7200 and thereafter stopped sending RAs.
> All windows machines behaved correctly and deprecated the addresses
> derived from
> that prefix. Outgoing connections no longer used it as source address,
> but
> incoming packets (like icmpv6 echo request) where answered due to the
> valid
> "ValidLifetime" value. ;)
> 
> Then in the second step (after some minutes of testing) I tried to re-
> activate
> the _same_ prefix (2001:db8:1:2::/64) by sending periodic RAs with
> PreferredLifetime=86400 and ValidLifetime=43200. And here the weird
> things
> began. On Vista and 7 the values for the "Lifetimes" where updated to
> the new
> ones derived from the RA, but the prefix status didn't change. It
still
> was
> stuck in status "deprecated". Hence the still valid IPv6 addresses
from
> that
> prefix (2001:db8:1:2::/64) wasn't used as source addresses for new
> connections,
> only old connections used it and incoming packets where answered.
> 
> On XP it was different. The prefix came back to life, changed to
status
> "preferred" and the system again used it's 2001:db8:1:2::/64 IPv6
> addresses as
> source address for new connections.
> 
> To proof it I replicated the test, and restarted all machines
> beforehand. But
> the result didn't change, hence it seems it is "stable" behavior.
> 
> I assume it's not the proper behavior, but found no clue in RFC4862
> (SLAAC)
> where I was looking for allowed status changes or similar.
> Has anybody seen a similar behavior or made similar tests with
different
> results?
> 
> BTW. I used radvd 1.1 on Ubuntu 9.04 on the router side.
> 
> cheers,
> Christian
> - ------------------
> gpg fingerprint:
> 31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAksVO/oACgkQ6kMW7HW86231ZwCdHIoyTIMPl7gVqFrtsrKSpRdZ
> MfQAn3z/pV04RMw1OVSNrzz4d5028pdl
> =26n8
> -----END PGP SIGNATURE-----

From chaz at chaz6.com  Tue Dec  1 23:53:15 2009
From: chaz at chaz6.com (Chris Hills)
Date: Tue, 01 Dec 2009 23:53:15 +0100
Subject: issue with SLAAC and deprecated IPv6 addresses on recent
	windowsversions
In-Reply-To: <46A2DD1223D7BF47B61799AFFBA8AD8907A93D72@PRDCG4EXVW01-1.OSS.PRD>
References: <4B153BFC.4040204@berkom.de>
	<46A2DD1223D7BF47B61799AFFBA8AD8907A93D72@PRDCG4EXVW01-1.OSS.PRD>
Message-ID: <hf46or$5r1$1@ger.gmane.org>

On 01/12/09 22:05, Scott Beuker wrote:
> Interesting bug, nice job in finding it.
> 
> I was talking to a friend who works at MS about what (if any) viable
> avenues there are to report a bug like this and actually stand a chance
> of getting it resolved. He recommend this:
> 
> http://connect.microsoft.com/WNDP/Feedback
> 
> I have no idea how much mileage you would get down this avenue, but if
> you're feeling optimistic give it a shot, and let me know and I'll be
> sure to create an account just to vote your bug up. :)

Here's another bug:

If you bind an ipv6 udp socket in the .Net framwork on windows, it will
reply from a privacy address even to packets sent to the EUI-64 address,
allowing a remote party to discovery the association between the addresses.



From hahn at berkom.de  Wed Dec  2 09:41:38 2009
From: hahn at berkom.de (Christian Hahn)
Date: Wed, 02 Dec 2009 09:41:38 +0100
Subject: issue with SLAAC and deprecated IPv6 addresses on
	recent	windowsversions
In-Reply-To: <726B24CA0C7F494795894989DCF1FE01048CC107@TK5EX14MBXC130.redmond.corp.microsoft.com>
References: <4B153BFC.4040204@berkom.de>
	<46A2DD1223D7BF47B61799AFFBA8AD8907A93D72@PRDCG4EXVW01-1.OSS.PRD>
	<726B24CA0C7F494795894989DCF1FE01048CC107@TK5EX14MBXC130.redmond.corp.microsoft.com>
Message-ID: <4B162842.9070307@berkom.de>

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

Sean Siler schrieb:
> Or you could get really luck and have the guy who owns IPv6 in Windows see your bug while browsing IPv6 Ops. :)
> 
> This is a terrific catch, Christian. I'll ask some folks to take a look at it.
That's nice news, Sean. Please let us know, if you can confirm that bug and also
if there is any progress in kicking it out ;)

cheers,
Christian
- ------------------
gpg fingerprint:
31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D

> 
> 
> Sean Siler
> Sr. IPv6 Program Manager
> Microsoft
> 
> 
> -----Original Message-----
> From: ipv6-ops-bounces+sean.siler=microsoft.com at lists.cluenet.de [mailto:ipv6-ops-bounces+sean.siler=microsoft.com at lists.cluenet.de] On Behalf Of Scott Beuker
> Sent: Tuesday, December 01, 2009 13:06
> To: Christian Hahn
> Cc: IPv6 Ops list
> Subject: RE: issue with SLAAC and deprecated IPv6 addresses on recent windowsversions
> 
> Interesting bug, nice job in finding it.
> 
> I was talking to a friend who works at MS about what (if any) viable
> avenues there are to report a bug like this and actually stand a chance
> of getting it resolved. He recommend this:
> 
> http://connect.microsoft.com/WNDP/Feedback
> 
> I have no idea how much mileage you would get down this avenue, but if
> you're feeling optimistic give it a shot, and let me know and I'll be
> sure to create an account just to vote your bug up. :)
> 
> Thanks,
> Scott
> 
> 
> 
>> -----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 Christian Hahn
>> Sent: Tuesday, December 01, 2009 8:54 AM
>> To: IPv6 Ops list
>> Subject: issue with SLAAC and deprecated IPv6 addresses on recent
>> windowsversions
>>
> Hi list,
> 
> In a lab I did some testing with SLAAC and different OSs and recently
> stumbled
> upon an issue on recent windows versions. It is only present on Vista
> and 7, not
> on XP. But let me tell you the story ...
> 
> I deprecated an formerly (by RA) announced IPv6 prefix (let's say
> 2001:db8:1:2::/64) by  sending some RAs with PreferredLifetime=0 and
> ValidLifetime=7200 and thereafter stopped sending RAs.
> All windows machines behaved correctly and deprecated the addresses
> derived from
> that prefix. Outgoing connections no longer used it as source address,
> but
> incoming packets (like icmpv6 echo request) where answered due to the
> valid
> "ValidLifetime" value. ;)
> 
> Then in the second step (after some minutes of testing) I tried to re-
> activate
> the _same_ prefix (2001:db8:1:2::/64) by sending periodic RAs with
> PreferredLifetime=86400 and ValidLifetime=43200. And here the weird
> things
> began. On Vista and 7 the values for the "Lifetimes" where updated to
> the new
> ones derived from the RA, but the prefix status didn't change. It
>> still
> was
> stuck in status "deprecated". Hence the still valid IPv6 addresses
>> from
> that
> prefix (2001:db8:1:2::/64) wasn't used as source addresses for new
> connections,
> only old connections used it and incoming packets where answered.
> 
> On XP it was different. The prefix came back to life, changed to
>> status
> "preferred" and the system again used it's 2001:db8:1:2::/64 IPv6
> addresses as
> source address for new connections.
> 
> To proof it I replicated the test, and restarted all machines
> beforehand. But
> the result didn't change, hence it seems it is "stable" behavior.
> 
> I assume it's not the proper behavior, but found no clue in RFC4862
> (SLAAC)
> where I was looking for allowed status changes or similar.
> Has anybody seen a similar behavior or made similar tests with
>> different
> results?
> 
> BTW. I used radvd 1.1 on Ubuntu 9.04 on the router side.
> 
> cheers,
> Christian
> ------------------
> gpg fingerprint:
> 31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAksWKD8ACgkQ6kMW7HW8623hcgCgpIXQzY5uCoBFW+NQtgb3wYHK
uM0An2ig9SFdJh1wUSbmpN0+p+VyuBo4
=Qn8+
-----END PGP SIGNATURE-----

From toivo at usf.edu  Wed Dec  2 16:21:45 2009
From: toivo at usf.edu (Voll, Toivo)
Date: Wed, 2 Dec 2009 10:21:45 -0500
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
Message-ID: <C5346EBB3EF3AA4C984D4F0F6D215427116A66B352@USFMAIL2.forest.usf.edu>

I just tried to replicate this, but it works for me. Mozilla reverts by default to IPv4, perhaps due to the certificate being wrong, but when forced https://www.ipv6.sixxs.net/main/, https://[2001:838:1:1:210:dcff:fe20:7c7c]/ it works just fine. Bottom of the page confirms: "SSL IPv6 connection from 2620:0:c30:13e8:28e6:d5cf:22a6:5ec6"

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)

--
Toivo Voll
Network Administrator
Information Technology Communications
University of South Florida


-----Original Message-----
From: ipv6-ops-bounces+toivo=usf.edu at lists.cluenet.de [mailto:ipv6-ops-bounces+toivo=usf.edu at lists.cluenet.de] On Behalf Of Alexander Mayrhofer
Sent: Tuesday, December 01, 2009 9:43 AM
To: ipv6-ops at lists.cluenet.de
Subject: SSL over IPv6 broken in Firefox for Windows...

Hello,

A colleague of mine has recently found out that the popular Firefox web
browser fails on https-URLs over IPv6, but only on Windows (Linux works
fine). The only way to get https sites working is to disable IPv6 in the
browser - not very useful for fostering IPv6 deployment. The full bug
report is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=513659

I think this is a major issues - however, i do understand that the focus
of the Mozilla developers is not necessarily on IPv6 yet. However, feel
free to vote for the bug if you think that it deserves more attention ;)

Thanks,

Alex

From martin at millnert.se  Wed Dec  2 17:49:22 2009
From: martin at millnert.se (Martin Millnert)
Date: Wed, 02 Dec 2009 17:49:22 +0100
Subject: issue with SLAAC and deprecated IPv6 addresses on recent
	windowsversions
In-Reply-To: <hf46or$5r1$1@ger.gmane.org>
References: <4B153BFC.4040204@berkom.de>
	<46A2DD1223D7BF47B61799AFFBA8AD8907A93D72@PRDCG4EXVW01-1.OSS.PRD>
	<hf46or$5r1$1@ger.gmane.org>
Message-ID: <1259772562.3628.1468.camel@hsa.vpn.anti>

On Tue, 2009-12-01 at 23:53 +0100, Chris Hills wrote:
> Here's another bug:
> 
> If you bind an ipv6 udp socket in the .Net framwork on windows, it will
> reply from a privacy address even to packets sent to the EUI-64 address,
> allowing a remote party to discovery the association between the addresses.
> 
> 

And here's a third:

Some Vista machines, it seems, use 6to4 and Teredo source addresses on
ethernet interfaces that are otherwise configured correctly -- at least,
they use gateway information received by RA, and v6 DNS resolvers
received by DHCPv6... I know this because some of the illegal packets
are in fact DNS queries.  Unless client machine owners have all
configured this statically, of course.. which I somehow doubt.

And a fourth:

Some clients with MAC's belonging mainly to Apple, do the same but using
fe80:: addresses.. Ie, tries to send DNS queries through a router with
such a source address.

Neither one of these bugs can be especially healthy, since classic BCP
asks me to not route these incorrect source addresses... and in the
Apple case it's quite difficult even route if I wanted to.

-- 
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/20091202/380bdfa8/attachment.bin 

From ayourtch at cisco.com  Wed Dec  2 23:18:10 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Wed, 2 Dec 2009 23:18:10 +0100 (CET)
Subject: SSL over IPv6 broken in Firefox for Windows...
In-Reply-To: <275E689A52D3FD4E922743D02EAEA8FA2C2623@server1.hotze.local>
References: <8BC845943058D844ABFC73D2220D466508C002FD@nics-mail.sbg.nic.at>
	<275E689A52D3FD4E922743D02EAEA8FA2C2623@server1.hotze.local>
Message-ID: <alpine.DEB.2.00.0912022242340.12419@ayourtch-lnx.stdio.be>

On Tue, 1 Dec 2009, Martin Hotze wrote:

> https://timatio.com/ bringt einen Fehler: "SSL hat einen Eintrag
> erhalten, der die maximal erlaubte L?nge ?berschritten hat.
> (Fehlercode: ssl_error_rx_record_too_long)"

This example looks like a glitch with the behaviour of the v6-to-v4 
proxy that enables the ipv6 connectivity for the site.

So the server side interprets browser's Client Hello as a "request",
and barfs in cleartext, which the browser tries to interpret as as a TLS 
record, and the first check that fails on that happens to be the length 
check, and the user sees the cryptic error message.


wireshark, try to connect, get the error, "follow tcp stream":

client->server:
...........K....#....b.__(.2.........,.R8$...F.
.......9.8.......5.........E.D.3.2...........A...../.........
.....
...*.........timatio.com.
.................#..


server->client:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>... to / not supported.<br />
</p>
<hr>
<address>Apache/2.2.9 Server at 188.40.65.74 Port 80</address>
</body></html>

client->server: (TLS Alert, unexpected message)
......

Then the connection gets reset.


Since the error code reveals the IPv4 address and port, I assume that 
there's the proxy/load balancer, that ends up doing just L4 forwarding 
between the port 443 on the IPv6 side and the port 80 on the IPv4 side, 
and for some reason does not do the TLS offloading.

I've sent the folks a message via the "feedback" form on their site.

cheers,
andrew

>
> Lg, Martin
>
>> -----Original Message-----
>> From: ipv6-ops-bounces+martin=hotze.com at lists.cluenet.de
> [mailto:ipv6-ops-
>> bounces+martin=hotze.com at lists.cluenet.de] On Behalf Of Alexander
>> Mayrhofer
>> Sent: Tuesday, December 01, 2009 3:43 PM
>> To: ipv6-ops at lists.cluenet.de
>> Subject: SSL over IPv6 broken in Firefox for Windows...
>>
>> Hello,
>>
>> A colleague of mine has recently found out that the popular Firefox
> web
>> browser fails on https-URLs over IPv6, but only on Windows (Linux
> works
>> fine). The only way to get https sites working is to disable IPv6 in
> the
>> browser - not very useful for fostering IPv6 deployment. The full
> bug
>> report is here:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=513659
>>
>> I think this is a major issues - however, i do understand that the
> focus
>> of the Mozilla developers is not necessarily on IPv6 yet. However,
> feel
>> free to vote for the bug if you think that it deserves more
> attention ;)
>>
>> Thanks,
>>
>> Alex
>

From hahn at berkom.de  Fri Dec  4 09:59:22 2009
From: hahn at berkom.de (Christian Hahn)
Date: Fri, 04 Dec 2009 09:59:22 +0100
Subject: issue with SLAAC and deprecated IPv6 addresses on recent windows
	versions
In-Reply-To: <4B153BFC.4040204@berkom.de>
References: <4B153BFC.4040204@berkom.de>
Message-ID: <4B18CF6A.5070607@berkom.de>

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

> Hi list,
Sean Siler just pointed me to an error in mail initial email, so I want to
correct things. In the email I've mixed up the values I've used in my second
step (to bring the prefix back to life). The correct values and the one I used
during the tests, are _PreferredLifetime=43200_ and _ValidLifetime=86400_.
Sorry for the confusion.

cheers,
Christian
> 
> In a lab I did some testing with SLAAC and different OSs and recently stumbled
> upon an issue on recent windows versions. It is only present on Vista and 7, not
> on XP. But let me tell you the story ...
> 
> I deprecated an formerly (by RA) announced IPv6 prefix (let's say
> 2001:db8:1:2::/64) by  sending some RAs with PreferredLifetime=0 and
> ValidLifetime=7200 and thereafter stopped sending RAs.
> All windows machines behaved correctly and deprecated the addresses derived from
> that prefix. Outgoing connections no longer used it as source address, but
> incoming packets (like icmpv6 echo request) where answered due to the valid
> "ValidLifetime" value. ;)
> 
> Then in the second step (after some minutes of testing) I tried to re-activate
> the _same_ prefix (2001:db8:1:2::/64) by sending periodic RAs with
> PreferredLifetime=86400 and ValidLifetime=43200. And here the weird things
> began. On Vista and 7 the values for the "Lifetimes" where updated to the new
> ones derived from the RA, but the prefix status didn't change. It still was
> stuck in status "deprecated". Hence the still valid IPv6 addresses from that
> prefix (2001:db8:1:2::/64) wasn't used as source addresses for new connections,
> only old connections used it and incoming packets where answered.
> 
> On XP it was different. The prefix came back to life, changed to status
> "preferred" and the system again used it's 2001:db8:1:2::/64 IPv6 addresses as
> source address for new connections.
> 
> To proof it I replicated the test, and restarted all machines beforehand. But
> the result didn't change, hence it seems it is "stable" behavior.
> 
> I assume it's not the proper behavior, but found no clue in RFC4862 (SLAAC)
> where I was looking for allowed status changes or similar.
> Has anybody seen a similar behavior or made similar tests with different results?
> 
> BTW. I used radvd 1.1 on Ubuntu 9.04 on the router side.
> 
> cheers,
> Christian
> ------------------
> gpg fingerprint:
> 31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAksYz2kACgkQ6kMW7HW8621CCQCdE/uSD+XOEuW5g3gfW19WRMRJ
htwAn1XLOQQOjVXOMK/7l4ItulOQePte
=mXWl
-----END PGP SIGNATURE-----

From cmeerw at cmeerw.org  Fri Dec  4 23:28:30 2009
From: cmeerw at cmeerw.org (Christof Meerwald)
Date: Fri, 4 Dec 2009 23:28:30 +0100
Subject: IPv6 brokenness experiment, November results
In-Reply-To: <hf2scu$dj1$1@ger.gmane.org>
References: <4B14D24E.6050707@redpill-linpro.com> <hf2scu$dj1$1@ger.gmane.org>
Message-ID: <20091204222830.GA8585@edge.cmeerw.net>

On Tue, 01 Dec 2009 11:50:01 +0100, Chris Hills wrote:
> I recently updated Opera to 10.10-4742 on Linux x86 (qt4 shared) and it
> now seems to prefer ipv4 when both ipv4 and ipv6 are available for the
> website, from a host with global unicast addresses.

It's actually worse than that - IPv6 has essentially been disabled in Opera
10.10 for Linux (it can't even connect to IPv6 only sites like
http://ipv6.google.com any more), see thread with msgid
<slrnhh85ob.g4d.NOSPAM-seeMySig at msgid.cmeerw.org> in the opera.linux
newsgroup.


Christof

-- 

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

From dougb at dougbarton.us  Sat Dec  5 00:26:23 2009
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 04 Dec 2009 15:26:23 -0800
Subject: IPv6 brokenness experiment, November results
In-Reply-To: <20091204222830.GA8585@edge.cmeerw.net>
References: <4B14D24E.6050707@redpill-linpro.com> <hf2scu$dj1$1@ger.gmane.org>
	<20091204222830.GA8585@edge.cmeerw.net>
Message-ID: <4B199A9F.7020306@dougbarton.us>

Christof Meerwald wrote:
> On Tue, 01 Dec 2009 11:50:01 +0100, Chris Hills wrote:
>> I recently updated Opera to 10.10-4742 on Linux x86 (qt4 shared) and it
>> now seems to prefer ipv4 when both ipv4 and ipv6 are available for the
>> website, from a host with global unicast addresses.
> 
> It's actually worse than that - IPv6 has essentially been disabled in Opera
> 10.10 for Linux (it can't even connect to IPv6 only sites like
> http://ipv6.google.com any more), see thread with msgid
> <slrnhh85ob.g4d.NOSPAM-seeMySig at msgid.cmeerw.org> in the opera.linux
> newsgroup.

In response to a message from a FreeBSD user on one of our lists
someone from Opera confirmed that there is a bug in 10.10 with their
fix to the IPv6 bug from earlier versions; and that they are working
on a fix to the new bug.


Stay tuned,

Doug

-- 

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

From ccaputo at alt.net  Tue Dec 15 06:31:04 2009
From: ccaputo at alt.net (Chris Caputo)
Date: Tue, 15 Dec 2009 05:31:04 +0000 (UTC)
Subject: router advertisements on open subnets
Message-ID: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>

On an open subnet, such as a public WiFi network, what is to stop a guest 
host from announcing IPv6 router advertisements (ICMPv6 type 134) to the 
subnet, thus competing with the intended gateway and potentially drawing 
traffic through/to it for analysis or blackholing?

Chris

From ek at google.com  Tue Dec 15 06:35:48 2009
From: ek at google.com (Erik Kline)
Date: Tue, 15 Dec 2009 14:35:48 +0900
Subject: router advertisements on open subnets
In-Reply-To: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
References: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
Message-ID: <2e8c64260912142135x40ca134eg9c90d7f559b7547b@mail.gmail.com>

2009/12/15 Chris Caputo <ccaputo at alt.net>:
> On an open subnet, such as a public WiFi network, what is to stop a guest
> host from announcing IPv6 router advertisements (ICMPv6 type 134) to the
> subnet, thus competing with the intended gateway and potentially drawing
> traffic through/to it for analysis or blackholing?
>
> Chris
>

This is what ra-guard is designed to prevent.

From swmike at swm.pp.se  Tue Dec 15 08:10:43 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 15 Dec 2009 08:10:43 +0100 (CET)
Subject: router advertisements on open subnets
In-Reply-To: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
References: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
Message-ID: <alpine.DEB.1.10.0912150808440.23464@uplift.swm.pp.se>

On Tue, 15 Dec 2009, Chris Caputo wrote:

> On an open subnet, such as a public WiFi network, what is to stop a 
> guest host from announcing IPv6 router advertisements (ICMPv6 type 134) 
> to the subnet, thus competing with the intended gateway and potentially 
> drawing traffic through/to it for analysis or blackholing?

On any type of LAN, there is nothing to stop this. The IETF has 
historically totally dropped the ball on this kind of security function to 
mitigate that problem (there is nothing to stop them doing ARP spoofing 
either), but nowadays there is the SAVI WG who are trying to standardize a 
framework both for IPv4 and v6 for vendors to implement so that this can 
be done securely.

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

From dwhite at olp.net  Tue Dec 15 08:18:20 2009
From: dwhite at olp.net (Dan White)
Date: Tue, 15 Dec 2009 01:18:20 -0600
Subject: router advertisements on open subnets
In-Reply-To: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
References: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
Message-ID: <20091215071819.GA32542@dan.olp.net>

On 15/12/09?05:31?+0000, Chris Caputo wrote:
>On an open subnet, such as a public WiFi network, what is to stop a guest 
>host from announcing IPv6 router advertisements (ICMPv6 type 134) to the 
>subnet, thus competing with the intended gateway and potentially drawing 
>traffic through/to it for analysis or blackholing?

http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-00

-- 
Dan White

From merike at doubleshotsecurity.com  Tue Dec 15 11:00:22 2009
From: merike at doubleshotsecurity.com (Merike Kaeo)
Date: Tue, 15 Dec 2009 02:00:22 -0800
Subject: router advertisements on open subnets
In-Reply-To: <alpine.DEB.1.10.0912150808440.23464@uplift.swm.pp.se>
References: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
	<alpine.DEB.1.10.0912150808440.23464@uplift.swm.pp.se>
Message-ID: <44F85A55-4E2A-4742-AF1D-5ADAC362336D@doubleshotsecurity.com>

Yeah - I'd follow SAVI and encourage you to add some input.  I've  
been hearing that more vendors are actually starting to ship SeND  
which could be useful.  I haven't heard of too many deployments yet  
(would love to hear otherwise).

- merike


On Dec 14, 2009, at 11:10 PM, Mikael Abrahamsson wrote:

> On Tue, 15 Dec 2009, Chris Caputo wrote:
>
>> On an open subnet, such as a public WiFi network, what is to stop  
>> a guest host from announcing IPv6 router advertisements (ICMPv6  
>> type 134) to the subnet, thus competing with the intended gateway  
>> and potentially drawing traffic through/to it for analysis or  
>> blackholing?
>
> On any type of LAN, there is nothing to stop this. The IETF has  
> historically totally dropped the ball on this kind of security  
> function to mitigate that problem (there is nothing to stop them  
> doing ARP spoofing either), but nowadays there is the SAVI WG who  
> are trying to standardize a framework both for IPv4 and v6 for  
> vendors to implement so that this can be done securely.
>
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se
>


From mohacsi at niif.hu  Tue Dec 15 11:55:19 2009
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Tue, 15 Dec 2009 11:55:19 +0100 (CET)
Subject: router advertisements on open subnets
In-Reply-To: <20091215071819.GA32542@dan.olp.net>
References: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
	<20091215071819.GA32542@dan.olp.net>
Message-ID: <alpine.BSF.2.00.0912151148390.23745@mignon.ki.iif.hu>



On Tue, 15 Dec 2009, Dan White wrote:

> On 15/12/09?05:31?+0000, Chris Caputo wrote:
>> On an open subnet, such as a public WiFi network, what is to stop a guest 
>> host from announcing IPv6 router advertisements (ICMPv6 type 134) to the 
>> subnet, thus competing with the intended gateway and potentially drawing 
>> traffic through/to it for analysis or blackholing?
>
> http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-00

Also look at:
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-03.txt

Regards,
 	Janos

From dwcarder at wisc.edu  Tue Dec 15 18:42:03 2009
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Tue, 15 Dec 2009 11:42:03 -0600
Subject: router advertisements on open subnets
In-Reply-To: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
References: <Pine.LNX.4.64.0912150519180.21906@nacho.alt.net>
Message-ID: <3828E958-9A3B-44A1-99AD-811378AF9265@wisc.edu>


On Dec 14, 2009, at 11:31 PM, Chris Caputo wrote:
> On an open subnet, such as a public WiFi network, what is to stop a  
> guest
> host from announcing IPv6 router advertisements (ICMPv6 type 134) to  
> the
> subnet, thus competing with the intended gateway and potentially  
> drawing
> traffic through/to it for analysis or blackholing?

If your equipment supports it, apply inbound ACL's as close to
the edge as you can.  We do this for various things like dhcp,
ra, mcast groups, etc we don't want.

Dale



From bit.gossip at chello.nl  Sat Dec 19 17:43:39 2009
From: bit.gossip at chello.nl (Bit Gossip)
Date: Sat, 19 Dec 2009 17:43:39 +0100
Subject: RA for a different router
Message-ID: <1261241019.4811.7.camel@localhost>

Experts,
do you know if it is possible to use RA for the router to advertise not
itself but some other address as the default router for the prefix?

I had a look also at DHCPv6 for the same purpose but no option, at list
with IOS for doing that.... Is it possible with DHCPv6?

3660(config-dhcp)#?
IPv6 DHCP configuration commands:
  default            Set a command to its defaults
  dns-server         DNS servers
  domain-name        Domain name to complete unqualified host names
  exit               Exit from DHCPv6 configuration mode
  import             Import options
  information        Information refresh option
  nis                NIS server options
  nisp               NISP server options
  no                 Negate a command or set its defaults
  prefix-delegation  IPv6 prefix delegation
  sip                SIP server options
  sntp               SNTP server options



Any other way?

Thanks,
bit


From nick-lists at netability.ie  Sat Dec 19 22:07:38 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Sat, 19 Dec 2009 21:07:38 +0000
Subject: RA for a different router
In-Reply-To: <1261241019.4811.7.camel@localhost>
References: <1261241019.4811.7.camel@localhost>
Message-ID: <4B2D409A.9040203@netability.ie>

On 19/12/2009 16:43, Bit Gossip wrote:
> do you know if it is possible to use RA for the router to advertise not
> itself but some other address as the default router for the prefix?

Basically, no.  This isn't part of the spec, because RA announcements come
from routers which can route traffic for a particular ipv6 prefix.
Otherwise, they wouldn't be announcing that they could route traffic for
that prefix, right?

> I had a look also at DHCPv6 for the same purpose but no option, at list
> with IOS for doing that.... Is it possible with DHCPv6?

One day, it will be possible to set a default gateway using dhcpv6, just
not yet.  The specification is in I-D draft-dec-dhcpv6-route-option.  I
posted a froth-at-the-mouth rant about this some while ago on nanog:

http://mailman.nanog.org/pipermail/nanog/2009-October/014222.html

I.O.W. if the current situation with regard to RA and dhcpv6 leaves you
speechless, your understanding of it is probably correct: that right now,
you will need to use both RA and DHCPv6 in order to get "functional" host
autoconfiguration.

Nick

From alex at digriz.org.uk  Sun Dec 20 11:01:01 2009
From: alex at digriz.org.uk (Alexander Clouter)
Date: Sun, 20 Dec 2009 10:01:01 +0000
Subject: RA for a different router
References: <1261241019.4811.7.camel@localhost>
	<4B2D409A.9040203@netability.ie>
Message-ID: <t79107-o5b.ln1@chipmunk.wormnet.eu>

Nick Hilliard <nick-lists at netability.ie> wrote:
>
> On 19/12/2009 16:43, Bit Gossip wrote:
>
>> do you know if it is possible to use RA for the router to advertise not
>> itself but some other address as the default router for the prefix?
> 
> Basically, no.  This isn't part of the spec, because RA announcements come
> from routers which can route traffic for a particular ipv6 prefix.
> Otherwise, they wouldn't be announcing that they could route traffic for
> that prefix, right?
> 
>> I had a look also at DHCPv6 for the same purpose but no option, at list
>> with IOS for doing that.... Is it possible with DHCPv6?
> 
> One day, it will be possible to set a default gateway using dhcpv6, just
> not yet.  The specification is in I-D draft-dec-dhcpv6-route-option.  I
> posted a froth-at-the-mouth rant about this some while ago on nanog:
>
I probably missed the memo but *why* would you want to send the default 
gateway in a DHCPv6 response when the local network topology would 
*know* far more accurately what is going on.  Especially when you 
consider gateway failover and that in theory you do *not* need anything 
like VRRP/HSRP as the glue to do this.

> I.O.W. if the current situation with regard to RA and dhcpv6 leaves you
> speechless, your understanding of it is probably correct: that right now,
> you will need to use both RA and DHCPv6 in order to get "functional" host
> autoconfiguration.
> 
Well if the world, the network sysadmin's and venduh's learnt about SRV 
records and SLP, we would not be in this situation.  You can already get 
a feel of how things Should Work(tm) with multicast NTP and SAP/SDP, we 
just need the rest of the world to wake up.

*sigh*

Bear in mind as a *organisation* network monkey I do not need DHCP-PD, 
but that's what stateless DHCPv6 is all about.

Cheers

-- 
Alexander Clouter
.sigmonster says: You will be given a post of trust and responsibility.


From LLE at dk.ibm.com  Sun Dec 20 16:02:21 2009
From: LLE at dk.ibm.com (Lasse Leegaard)
Date: Sun, 20 Dec 2009 16:02:21 +0100
Subject: AUTO: Lasse Leegaard is out of the office. (returning 04-01-2010)
Message-ID: <OFD314A85E.0D67270F-ONC1257692.00529D2D-C1257692.00529D2D@dk.ibm.com>


I am out of the office until 04-01-2010.




Note: This is an automated response to your message  "ipv6-ops Digest, Vol
57, Issue 9" sent on 20/12/09 12:00:01.

This is the only notification you will receive while this person is away.


From nick-lists at netability.ie  Sun Dec 20 21:56:32 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Sun, 20 Dec 2009 20:56:32 +0000
Subject: RA for a different router
In-Reply-To: <t79107-o5b.ln1@chipmunk.wormnet.eu>
References: <1261241019.4811.7.camel@localhost>	<4B2D409A.9040203@netability.ie>
	<t79107-o5b.ln1@chipmunk.wormnet.eu>
Message-ID: <4B2E8F80.7050003@netability.ie>

On 20/12/2009 10:01, Alexander Clouter wrote:
> I probably missed the memo but *why* would you want to send the default 
> gateway in a DHCPv6 response when the local network topology would 
> *know* far more accurately what is going on.  Especially when you 
> consider gateway failover and that in theory you do *not* need anything 
> like VRRP/HSRP as the glue to do this.

RA gateway fail-over takes $client_ra_timeout seconds for clients to
realise that the gateway has disappeared, where $client_ra_timeout is
substantially greater than $ra_announcement_interval (probably by a factor
of at least 3 in order to cope with packet loss, etc).  Typically,
$ra_announcement_interval will measured in seconds, possibly tens of
seconds.  This leads to fail-over times of tens of seconds to possibly
minutes.   vrrp / hsrp / glbp will typically provide fail-over in an order
of magnitude less time.

As a network operator, I would be much happier depending for network
stability on vrrp & friends (which I can control) rather than waiting for
each client machine on a potentially large network to reconfigure its
default gateway (which I can't control, or at least control well or easily).

Also, on this particular argument, if you have a network where your
dhcp(v4|v6)-announced gateway is unavailable, you either have a broken
network design or a network which is broken to the extent that the use of
RA probably wouldn't have made much difference in the first place.  I have
seen otherwise very smart people argue that because they have seen
anecdotal problems with default gateways disappearing on a dhcp-managed
network, that therefore DHCP+default gateway announcements are therefore a
broken design, concluding that RA is superior.

Charitably, this argument is about as convincing as "Monsieur, (a+bn)/n =
x; donc Dieu existe! R?pondez!".

> Well if the world, the network sysadmin's and venduh's learnt about SRV 
> records and SLP, we would not be in this situation.  You can already get 
> a feel of how things Should Work(tm) with multicast NTP and SAP/SDP, we 
> just need the rest of the world to wake up.

Well, maybe, maybe not.  There's never been a shortage of ideas about L4-L7
service availability / auto-provisioning throughout the years, whether
based on SRV records or SLP or even ACAP (rfc2244, not the more recent DRM
abomination) or any of the other protocols scattered like bones in the
graveyard section of the RFCs.  The internet community never went down that
road, which in some ways is quite the pity - at a certain stage, I remember
thinking how useful some of these things might be.  But the service
provider IP access model diverged from the early-days
service-provider-provides-all model, and we have quite a different internet
now than what the original authors of those protocols probably ever
envisaged.  This is certainly a good topic of discussion for a long evening
over lots of beer.  That, and the problems of the world.

> *sigh*
> 
> Bear in mind as a *organisation* network monkey I do not need DHCP-PD, 
> but that's what stateless DHCPv6 is all about.

grief, don't get me started on stateless vs stateful dhcpv6. :-(

Nick

From otroan at employees.org  Mon Dec 21 06:11:28 2009
From: otroan at employees.org (Ole Troan)
Date: Mon, 21 Dec 2009 13:11:28 +0800
Subject: RA for a different router
In-Reply-To: <4B2E8F80.7050003@netability.ie>
References: <1261241019.4811.7.camel@localhost>	<4B2D409A.9040203@netability.ie>
	<t79107-o5b.ln1@chipmunk.wormnet.eu>
	<4B2E8F80.7050003@netability.ie>
Message-ID: <B2E7BC66-E1CD-4821-A446-C3A702243DCB@employees.org>

Nick,

>> I probably missed the memo but *why* would you want to send the default 
>> gateway in a DHCPv6 response when the local network topology would 
>> *know* far more accurately what is going on.  Especially when you 
>> consider gateway failover and that in theory you do *not* need anything 
>> like VRRP/HSRP as the glue to do this.
> 
> RA gateway fail-over takes $client_ra_timeout seconds for clients to
> realise that the gateway has disappeared, where $client_ra_timeout is
> substantially greater than $ra_announcement_interval (probably by a factor
> of at least 3 in order to cope with packet loss, etc).  Typically,
> $ra_announcement_interval will measured in seconds, possibly tens of
> seconds.  This leads to fail-over times of tens of seconds to possibly
> minutes.   vrrp / hsrp / glbp will typically provide fail-over in an order
> of magnitude less time.

this is not quite correct. Neighbor Unreachability Detection is the mechanism used by a host to detect failure of one of its default routers. as a part of NUD a host can detect that a connection doesn't make forward progress, e.g not receiving TCP acks or that active probing (NS/NA) fails. the latter uses a default timer of 30 seconds, but that can be configured by the operator (included in RA messages), down to milliseconds. in IPv6 a host can use multiple default routers at the same time, so the effect of a single default router failure and the time it takes for all hosts to converge varies.

> As a network operator, I would be much happier depending for network
> stability on vrrp & friends (which I can control) rather than waiting for
> each client machine on a potentially large network to reconfigure its
> default gateway (which I can't control, or at least control well or easily).

you can control it to some degree with NUD, but you are correct in that VRRP/HSRP gives generally quicker convergence and less surprises.

cheers,
Ole




From tore.anderson at redpill-linpro.com  Mon Dec 21 09:21:34 2009
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Mon, 21 Dec 2009 09:21:34 +0100 (CET)
Subject: RA for a different router
In-Reply-To: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>
Message-ID: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>

* Alexander Clouter

> I probably missed the memo but *why* would you want to send the default 
> gateway in a DHCPv6 response when the local network topology would 
> *know* far more accurately what is going on.  Especially when you 
> consider gateway failover and that in theory you do *not* need
> anything like VRRP/HSRP as the glue to do this.

* Nick Hilliard

> RA gateway fail-over takes $client_ra_timeout seconds for clients to
> realise that the gateway has disappeared, where $client_ra_timeout is
> substantially greater than $ra_announcement_interval (probably by a
> factor of at least 3 in order to cope with packet loss, etc).
> Typically, $ra_announcement_interval will measured in seconds, possibly
> tens of seconds.  This leads to fail-over times of tens of seconds to
> possibly minutes.   vrrp / hsrp / glbp will typically provide fail-over
> in an order of magnitude less time.

I too would prefer using VRRP to a failover mechanism depending on RA
information being quickly timed out on the hosts.  But what is gained by
using DHCPv6 for configuring the default gateway/virtual router, compared
to simply announcing it in a standard RA packet?

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From sthaug at nethelp.no  Mon Dec 21 09:29:29 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 21 Dec 2009 09:29:29 +0100 (CET)
Subject: RA for a different router
In-Reply-To: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
References: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>
	<1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
Message-ID: <20091221.092929.41638815.sthaug@nethelp.no>

> I too would prefer using VRRP to a failover mechanism depending on RA
> information being quickly timed out on the hosts.  But what is gained by
> using DHCPv6 for configuring the default gateway/virtual router, compared
> to simply announcing it in a standard RA packet?

Old discussion. Think of aggregation routers with many thousands of
customers. Customers get their addresses from DHCP, which also is
connected to backend support systems (so the support people can see,
for instance, which address does customer X have and when was it last
renewed).

Some of us crazy service provider types want our DHCP infrastructure
to handle *all* customer related address info, even including default
gateway. This is well established in the IPv4 world, and we want the
IPv6 world to work the same way.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From bjorn at mork.no  Mon Dec 21 10:18:30 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 21 Dec 2009 10:18:30 +0100
Subject: RA for a different router
In-Reply-To: <20091221.092929.41638815.sthaug@nethelp.no> (sthaug@nethelp.no's
	message of "Mon, 21 Dec 2009 09:29:29 +0100 (CET)")
References: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>
	<1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
Message-ID: <877hsgy9ax.fsf@nemi.mork.no>

sthaug at nethelp.no writes:

>> I too would prefer using VRRP to a failover mechanism depending on RA
>> information being quickly timed out on the hosts.  But what is gained by
>> using DHCPv6 for configuring the default gateway/virtual router, compared
>> to simply announcing it in a standard RA packet?
>
> Old discussion. Think of aggregation routers with many thousands of
> customers. Customers get their addresses from DHCP, which also is
> connected to backend support systems (so the support people can see,
> for instance, which address does customer X have and when was it last
> renewed).
>
> Some of us crazy service provider types want our DHCP infrastructure
> to handle *all* customer related address info, even including default
> gateway. This is well established in the IPv4 world, and we want the
> IPv6 world to work the same way.

But the default gateway isn't really customer related.  It depends on
where the customer is connected.

With IPv4, you have to maintain a strong binding between the gateway
address and the delegated pre^H^H^Haddress, as that's the only way you
can ensure that the client can reach the gateway. So your DHCP server
will have to calculate both gateway and delegated address based on the
giaddr field.  This makes it logical to keep the gateway together with
the address.  I fully agree with that.

But this is not necessary for IPv6. The client can use any link local
gateway address regardless of the delegated prefix.  You know it's
reachable on that link.  You still want to aggregate of course, so the
prefix *may* depend on where the customer is connected.  However, there
is no need to make it as strict as with IPv4.  You can choose to
aggregate on a cluster of access routers, letting them share e.g. a /32.
Having the routers announce the default gateway (and WAN link prefix if
used), and keeping only the delegated prefix in your backend database,
makes it very simple to move an end user within an access router
cluster.  Or even to another cluster if you allow leaking some of the
delegated /48s (or /56s or whatever).




Bj?rn

From nick-lists at netability.ie  Mon Dec 21 12:25:36 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Mon, 21 Dec 2009 11:25:36 +0000
Subject: RA for a different router
In-Reply-To: <B2E7BC66-E1CD-4821-A446-C3A702243DCB@employees.org>
References: <1261241019.4811.7.camel@localhost>	<4B2D409A.9040203@netability.ie>
	<t79107-o5b.ln1@chipmunk.wormnet.eu>
	<4B2E8F80.7050003@netability.ie>
	<B2E7BC66-E1CD-4821-A446-C3A702243DCB@employees.org>
Message-ID: <4B2F5B30.3060808@netability.ie>

On 21/12/2009 05:11, Ole Troan wrote:
> this is not quite correct. Neighbor Unreachability Detection is the
> mechanism used by a host to detect failure of one of its default
> routers. as a part of NUD a host can detect that a connection doesn't
> make forward progress, e.g not receiving TCP acks or that active probing
> (NS/NA) fails. the latter uses a default timer of 30 seconds, but that
> can be configured by the operator (included in RA messages), down to
> milliseconds. in IPv6 a host can use multiple default routers at the
> same time, so the effect of a single default router failure and the time
> it takes for all hosts to converge varies.

This will make no practical difference for default gateway detection, as
the default gateway is effectively a traffic sink from the point of view of
the client.  So unless you crank up your neighbor solicitation packet rate
to something large (think how this might scale on a large corporate LAN),
it's really not going to help much.  I think I'd prefer to stick with vrrp
et al.  Again there's an issue here of operator control - it's far easier
to control vrrp than a pile of clients running potentially disparate
operating systems.

Nick

From nick-lists at netability.ie  Mon Dec 21 12:36:00 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Mon, 21 Dec 2009 11:36:00 +0000
Subject: RA for a different router
In-Reply-To: <877hsgy9ax.fsf@nemi.mork.no>
References: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>	<1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>	<20091221.092929.41638815.sthaug@nethelp.no>
	<877hsgy9ax.fsf@nemi.mork.no>
Message-ID: <4B2F5DA0.8010401@netability.ie>

On 21/12/2009 09:18, Bj?rn Mork wrote:
> But this is not necessary for IPv6. The client can use any link local
> gateway address regardless of the delegated prefix.

This is part of the problem.  We learned in the early 1990s that the
default configuration of sun workstations of blindly accepting routing
updates from any source on a LAN was actually a rather bad idea.

As an operator in the general case, I simply don't _want_ random clients on
my lan saying "hellooooo!  i'm a default gateway over here!", and other
random clients blindly believing them.  That just creates a requirement to
filter out another protocol from your LAN clients.

> You know it's reachable on that link.

You know that the gateway address is reachable, but you don't know whether
the machine at that address will do anything meaningful with packets.

Nick

From bjorn at mork.no  Mon Dec 21 13:03:50 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 21 Dec 2009 13:03:50 +0100
Subject: RA for a different router
In-Reply-To: <4B2F5DA0.8010401@netability.ie> (Nick Hilliard's message of
	"Mon, 21 Dec 2009 11:36:00 +0000")
References: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>
	<1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
	<877hsgy9ax.fsf@nemi.mork.no> <4B2F5DA0.8010401@netability.ie>
Message-ID: <878wcwsfdl.fsf@nemi.mork.no>

Nick Hilliard <nick-lists at netability.ie> writes:
> On 21/12/2009 09:18, Bj?rn Mork wrote:
>> But this is not necessary for IPv6. The client can use any link local
>> gateway address regardless of the delegated prefix.
>
> This is part of the problem.  We learned in the early 1990s that the
> default configuration of sun workstations of blindly accepting routing
> updates from any source on a LAN was actually a rather bad idea.
>
> As an operator in the general case, I simply don't _want_ random clients on
> my lan saying "hellooooo!  i'm a default gateway over here!", and other
> random clients blindly believing them.  That just creates a requirement to
> filter out another protocol from your LAN clients.

So you need to trust the *link*.  Putting the gateway in DHCPv6 won't
change this, unless you authenticate the ISP.  And I don't really see
any ISPs prepared to support that...  I expect most of them will either
provide a true point-to-point link, or emulate one by filtering
multicast and broadcast from end users.

>> You know it's reachable on that link.
>
> You know that the gateway address is reachable, but you don't know whether
> the machine at that address will do anything meaningful with packets.

Well, that's the same for DHCP (v4) as well.  You have to blindly trust
the gateway address you get.


Bj?rn

From nick-lists at netability.ie  Mon Dec 21 13:23:30 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Mon, 21 Dec 2009 12:23:30 +0000
Subject: RA for a different router
In-Reply-To: <878wcwsfdl.fsf@nemi.mork.no>
References: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>	<1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>	<20091221.092929.41638815.sthaug@nethelp.no>	<877hsgy9ax.fsf@nemi.mork.no>
	<4B2F5DA0.8010401@netability.ie> <878wcwsfdl.fsf@nemi.mork.no>
Message-ID: <4B2F68C2.1010509@netability.ie>

On 21/12/2009 12:03, Bj?rn Mork wrote:
> So you need to trust the *link*. 

You need to trust the link anyway.  No change here.

> Putting the gateway in DHCPv6 won't
> change this, unless you authenticate the ISP.  And I don't really see
> any ISPs prepared to support that...  I expect most of them will either
> provide a true point-to-point link, or emulate one by filtering
> multicast and broadcast from end users.

Yes, bridged isp connections will require ra-guard before ipv6 becomes a
possibility for clients using this.

>>> You know it's reachable on that link.
>>
>> You know that the gateway address is reachable, but you don't know whether
>> the machine at that address will do anything meaningful with packets.
> 
> Well, that's the same for DHCP (v4) as well.  You have to blindly trust
> the gateway address you get.

Yep, correct - see my previous points in other emails.

Overall, I cannot see any real operational advantage to splitting
auto-configuration between ra and dhcpv6.  It's simpler and more manageable
with a single protocol.

Nick

From gert at space.net  Mon Dec 21 23:53:37 2009
From: gert at space.net (Gert Doering)
Date: Mon, 21 Dec 2009 23:53:37 +0100
Subject: RA for a different router
In-Reply-To: <20091221.092929.41638815.sthaug@nethelp.no>
References: <756789875.43470.1261383120635.JavaMail.root@claudius.linpro.no>
	<1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
Message-ID: <20091221225337.GJ32226@Space.Net>

Hi,

On Mon, Dec 21, 2009 at 09:29:29AM +0100, sthaug at nethelp.no wrote:
> Some of us crazy service provider types want our DHCP infrastructure
> to handle *all* customer related address info, even including default
> gateway. This is well established in the IPv4 world, and we want the
> IPv6 world to work the same way.

Don't you dare giving customers a single dynamic IPv6 address and force
them to use NAT/PAT... I'll come after you!!

"IPv6 is not IPv4"

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 sthaug at nethelp.no  Tue Dec 22 09:43:42 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Tue, 22 Dec 2009 09:43:42 +0100 (CET)
Subject: RA for a different router
In-Reply-To: <20091221225337.GJ32226@Space.Net>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
	<20091221225337.GJ32226@Space.Net>
Message-ID: <20091222.094342.74662487.sthaug@nethelp.no>

> > Some of us crazy service provider types want our DHCP infrastructure
> > to handle *all* customer related address info, even including default
> > gateway. This is well established in the IPv4 world, and we want the
> > IPv6 world to work the same way.
> 
> Don't you dare giving customers a single dynamic IPv6 address and force
> them to use NAT/PAT... I'll come after you!!

You're off that hook since we plan to give our residential customers a
/56 :-)

> "IPv6 is not IPv4"

Too true. However, making IPv6 more different from IPv4 than necessary
(e.g. the absolute refusal, among some people, to even consider the
the possibility of a DHCPv6 server handing out a default gateway) is
not helping deployment.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From ipv6-ops at c0mplx.org  Tue Dec 22 09:49:17 2009
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Tue, 22 Dec 2009 09:49:17 +0100
Subject: RA for a different router
In-Reply-To: <20091222.094342.74662487.sthaug@nethelp.no>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
	<20091221225337.GJ32226@Space.Net>
	<20091222.094342.74662487.sthaug@nethelp.no>
Message-ID: <20091222084917.GA6431@home.opsec.eu>

Hi!

> > "IPv6 is not IPv4"
> 
> Too true. However, making IPv6 more different from IPv4 than necessary
> is not helping deployment.

Yes. I have some nice little case here:

German DTAG DSL platform. IPv6 via PPPoE. Customer:

lan----cust-router------[dsl]----our-l2tp-endpoint
       speaking pppoe
      lan        wan

Our l2tp endpoint: cisco 7206, ios 12.4(25b).

So, I can suggest a prefix to the cust-router for his LAN interface.
But assigning anything other than a link-local prefix to the wan
side using radius seems to be impossible ?

Any suggestions ? IOS releases where this might be possible ?

-- 
pi at opsec.eu            +49 171 3101372                        11 years to go !

From madams at netcologne.de  Tue Dec 22 10:25:40 2009
From: madams at netcologne.de (Michael Adams)
Date: Tue, 22 Dec 2009 10:25:40 +0100
Subject: RA for a different router
In-Reply-To: <20091222084917.GA6431@home.opsec.eu>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>,
	<20091222.094342.74662487.sthaug@nethelp.no>,
	<20091222084917.GA6431@home.opsec.eu>
Message-ID: <4B309094.6050.F62E0525@madams.netcologne.de>

Kurt Jaeger,  22 Dec 2009 9:49:

> German DTAG DSL platform. IPv6 via PPPoE. Customer:
> 
> lan----cust-router------[dsl]----our-l2tp-endpoint
>        speaking pppoe
>       lan        wan
> 
> Our l2tp endpoint: cisco 7206, ios 12.4(25b).
> 
> So, I can suggest a prefix to the cust-router for his LAN interface.
> But assigning anything other than a link-local prefix to the wan
> side using radius seems to be impossible ?

What about a local v6 pool?  I just checked it with 12.4(24)T2 on a 7206.

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 ipv6-ops at c0mplx.org  Tue Dec 22 10:42:24 2009
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Tue, 22 Dec 2009 10:42:24 +0100
Subject: RA for a different router
In-Reply-To: <4B309094.6050.F62E0525@madams.netcologne.de>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091222.094342.74662487.sthaug@nethelp.no>
	<20091222084917.GA6431@home.opsec.eu>
	<4B309094.6050.F62E0525@madams.netcologne.de>
Message-ID: <20091222094224.GB6431@home.opsec.eu>

Hi!

> > German DTAG DSL platform. IPv6 via PPPoE. Customer:
> >
> > lan----cust-router------[dsl]----our-l2tp-endpoint
> >        speaking pppoe
> >       lan        wan
> >
> > Our l2tp endpoint: cisco 7206, ios 12.4(25b).
> >
> > So, I can suggest a prefix to the cust-router for his LAN interface.
> > But assigning anything other than a link-local prefix to the wan
> > side using radius seems to be impossible ?
> 
> What about a local v6 pool?  I just checked it with 12.4(24)T2 on a 7206.

If I use the local v6 pool, how can I statically assign the wan IP ?

I want to know which customer gets which wan IPv6 8-)

-- 
pi at opsec.eu            +49 171 3101372                        11 years to go !

From madams at netcologne.de  Tue Dec 22 11:15:56 2009
From: madams at netcologne.de (Michael Adams)
Date: Tue, 22 Dec 2009 11:15:56 +0100
Subject: RA for a different router
In-Reply-To: <20091222094224.GB6431@home.opsec.eu>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>,
	<4B309094.6050.F62E0525@madams.netcologne.de>,
	<20091222094224.GB6431@home.opsec.eu>
Message-ID: <4B309C5C.10183.F65C0D05@madams.netcologne.de>

Kurt Jaeger,  22 Dec 2009 10:42:

> If I use the local v6 pool, how can I statically assign the wan IP ?

Right. 'statically' might be a problem :)
 
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 marcoh at marcoh.net  Tue Dec 22 11:27:14 2009
From: marcoh at marcoh.net (Marco Hogewoning)
Date: Tue, 22 Dec 2009 11:27:14 +0100
Subject: RA for a different router
In-Reply-To: <20091222084917.GA6431@home.opsec.eu>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
	<20091221225337.GJ32226@Space.Net>
	<20091222.094342.74662487.sthaug@nethelp.no>
	<20091222084917.GA6431@home.opsec.eu>
Message-ID: <C8BB442C-F3CD-45EE-B46E-576ACF3330EF@marcoh.net>


On 22 dec 2009, at 09:49, Kurt Jaeger wrote:

> Hi!
> 
>>> "IPv6 is not IPv4"
>> 
>> Too true. However, making IPv6 more different from IPv4 than necessary
>> is not helping deployment.
> 
> Yes. I have some nice little case here:
> 
> German DTAG DSL platform. IPv6 via PPPoE. Customer:
> 
> lan----cust-router------[dsl]----our-l2tp-endpoint
>       speaking pppoe
>      lan        wan
> 
> Our l2tp endpoint: cisco 7206, ios 12.4(25b).
> 
> So, I can suggest a prefix to the cust-router for his LAN interface.
> But assigning anything other than a link-local prefix to the wan
> side using radius seems to be impossible ?
> 
> Any suggestions ? IOS releases where this might be possible ?


Why wouild you want anything else then a link-local on the WAN interface ? It works perfectly well without any GUA and all you do  by assigning one is create another point to secure and a second address pool to manage.

I notice this requirement popping everytime and nobody can tell me what the need is. ICMP can be sourced from a 'virtual interface' and that is what all CPE I tested so far do, the current IETF drafts cater for this, it's covered for by WAA-6/WPD-5 in draft-ietf-v6ops-ipv6-cpe-router-03.

MarcoH


From ipv6-ops at c0mplx.org  Tue Dec 22 11:41:53 2009
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Tue, 22 Dec 2009 11:41:53 +0100
Subject: RA for a different router
In-Reply-To: <C8BB442C-F3CD-45EE-B46E-576ACF3330EF@marcoh.net>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
	<20091221225337.GJ32226@Space.Net>
	<20091222.094342.74662487.sthaug@nethelp.no>
	<20091222084917.GA6431@home.opsec.eu>
	<C8BB442C-F3CD-45EE-B46E-576ACF3330EF@marcoh.net>
Message-ID: <20091222104153.GC6431@home.opsec.eu>

Hi!

> >>> "IPv6 is not IPv4"

> >> Too true. However, making IPv6 more different from IPv4 than necessary
> >> is not helping deployment.
> > 
> > Yes. I have some nice little case here:
> > 
> > German DTAG DSL platform. IPv6 via PPPoE. Customer:
> > 
> > lan----cust-router------[dsl]----our-l2tp-endpoint
> >       speaking pppoe
> >      lan        wan
> > 
> > Our l2tp endpoint: cisco 7206, ios 12.4(25b).
> > 
> > So, I can suggest a prefix to the cust-router for his LAN interface.
> > But assigning anything other than a link-local prefix to the wan
> > side using radius seems to be impossible ?
> > 
> > Any suggestions ? IOS releases where this might be possible ?

> Why wouild you want anything else then a link-local on the WAN
> interface ?

Good question, I agree. But, it was useful in the ipv4 past,
and I assume it will be useful in the v6 future.

> It works perfectly well without any GUA

I can't test it from the monitoring host, which is not on the local link.

> and all you do
> by assigning one is create another point to secure

I have to secure it if it is link-local or GUA, anyway.

> and a second address pool to manage.

Yes, but we do this all the time, it's not a big problem.

> ICMP can be sourced from a 'virtual interface'
> and that is what all CPE I tested so far do, the current IETF drafts
> cater for this, it's covered for by WAA-6/WPD-5 in
> draft-ietf-v6ops-ipv6-cpe-router-03.

As soon as someone does firewalling on all his LAN prefixes with his
CPE, I'd like to have a seperate IP to test 8-)

I have one such case right now in the v4 world, where the
customer insists that he's not probed from our monitoring, but
complains if the link is missing 8-) Beautiful 8-)

Yes, yes, check link state or interface counters instead, all this
is possible, but it's not as nice as just sending a ping 8-)

> I notice this requirement popping everytime and nobody can tell
> me what the need is.

Since when is "Because I want to!" together with foot-stomping not
reason enough 8-) ?

-- 
pi at opsec.eu            +49 171 3101372                        11 years to go !

From otroan at employees.org  Tue Dec 22 11:44:19 2009
From: otroan at employees.org (Ole Troan)
Date: Tue, 22 Dec 2009 18:44:19 +0800
Subject: RA for a different router
In-Reply-To: <20091222094224.GB6431@home.opsec.eu>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091222.094342.74662487.sthaug@nethelp.no>
	<20091222084917.GA6431@home.opsec.eu>
	<4B309094.6050.F62E0525@madams.netcologne.de>
	<20091222094224.GB6431@home.opsec.eu>
Message-ID: <DB8CF56B-A54B-4667-B29F-3CE93CB08CED@employees.org>

>>> German DTAG DSL platform. IPv6 via PPPoE. Customer:
>>> 
>>> lan----cust-router------[dsl]----our-l2tp-endpoint
>>>       speaking pppoe
>>>      lan        wan
>>> 
>>> Our l2tp endpoint: cisco 7206, ios 12.4(25b).
>>> 
>>> So, I can suggest a prefix to the cust-router for his LAN interface.
>>> But assigning anything other than a link-local prefix to the wan
>>> side using radius seems to be impossible ?
>> 
>> What about a local v6 pool?  I just checked it with 12.4(24)T2 on a 7206.
> 
> If I use the local v6 pool, how can I statically assign the wan IP ?
> 
> I want to know which customer gets which wan IPv6 8-)

use DHCP for address assignment.
or reserve one subnet of the delegated prefix for an internal management interface.

I think your case is covered in:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-03

/ot

From marcoh at marcoh.net  Tue Dec 22 13:06:15 2009
From: marcoh at marcoh.net (Marco Hogewoning)
Date: Tue, 22 Dec 2009 13:06:15 +0100
Subject: RA for a different router
In-Reply-To: <20091222104153.GC6431@home.opsec.eu>
References: <1697675154.43507.1261383694815.JavaMail.root@claudius.linpro.no>
	<20091221.092929.41638815.sthaug@nethelp.no>
	<20091221225337.GJ32226@Space.Net>
	<20091222.094342.74662487.sthaug@nethelp.no>
	<20091222084917.GA6431@home.opsec.eu>
	<C8BB442C-F3CD-45EE-B46E-576ACF3330EF@marcoh.net>
	<20091222104153.GC6431@home.opsec.eu>
Message-ID: <BC9D0EF9-796B-4E9A-B448-E6ADE9D19CDC@marcoh.net>

>> Why wouild you want anything else then a link-local on the WAN
>> interface ?
> 
> Good question, I agree. But, it was useful in the ipv4 past,
> and I assume it will be useful in the v6 future.

I think it depends on perspective there, did you or did you not have an IPv4 address on the WAN side when using a regular residential setup using a single IP and NAT. Does it really belong to the WAN interface is or it some 'virtual', almost quantum like behavior where it only is there when you look for it.

>> It works perfectly well without any GUA
> 
> I can't test it from the monitoring host, which is not on the local link.

I have this running with multiple IOS versions, AVM's FRITZ!box and some beta's from vendors who do not whish to be disclosded at this point in time, I must add we use Juniper E-series (9.2.x) as edge routers on our end. We only use DHCPv6-PD at this point in time and it works perfectly, CPE negotiates IPv6CP and after establishing a link-local fires of DHCPv6 on which it will only get an IA_PD.

>> and all you do
>> by assigning one is create another point to secure
> 
> I have to secure it if it is link-local or GUA, anyway.

That was too short, let me explain :)

(please note that when it comes to IPv6 size does matter and I'm not talking about those 96 bits)

There are multiple ways on handling this:

1)	Use SLAAC on the wan interface, this can be done 2 ways:
	1a)	seperate /64 per PPP interface
	1b)	use one /64 for multiple customers
2)	Use DHCPv6 and assign IA_NA

We never pushed the limit on it, but considering option 1a you have a lot of stuff to keep track of. Each /64 requires an entry in the forwarding table and you need to keep track of a couple of counters, this might be a working setup when running a couple of hundred customers, but what if you run boxes with 40k connections ? Although RA is multicast you have to build seperate packeta for each individual link which can and will eat a lot resources.

Option 1b saves you a lot of trouble in the sense you can truly multicast and modern hardware should not be bothered to much by it, however you still need a lot of entries in your forwarding and neighbor tables which are redundant. This is also the point where security comes around the corner, how do you keep track of which user uses which address (and at which point in time). Now you might already have a database of mac-addresses, but how to secure your network from spoofing ? And keep in mind we are talking GUA here, what would happen if I would manage to assign that address to a more intelligent form of hardware like my workstation, it would not take much to come up with a lot of addresses to do evil from (spam/virusses). Source address verification and uRPF will work sort of but since it's supposed to be stateless a DAD should be enough to secure an address and have it forwarded.

This is of course fixable by putting up some ACLs on your side of the network to limit those addresses to certain protocols (ICMPv6) but this does mean extra overhead in managing the network and yes, if your network is only a few boxes and a couple of hundred customers this is not a problem, if you try an attempt at world dominination and you reach the million mark this all of sudden can be quite a headache and possibly requires  a substantial investment in patches on management software.

Option 2 will at least mean you have a trace on who-is-who and with a bit of luck your $vendor allows to control SA-validate by DHCP taking away the risk of spoofing. What is left again is a lot of extra and theoretically redudant slots in the forwarding table and another 'thing' to manage which might look easy when you're not that big.

One final point to keep in mind from an operator perspective are goverment regulations regarding data retention and lawfull intercept, by assiging additional addresses you might be forced to also register and keep additional data and suffer the cost and pain that comes with it.

The only workaround we came up with when discussing wether we should go for GUA on the WAN was to assign the wan address in a subnet which was part of the IA_PD assigned to this customer, this takes away a lot of the track-and-trace issues but the question of scalabillity stays around.

And yes to answer your question, you have to secure the modem anyway and as far as the simple-security draft is properly implemented it shouldn't be an issue, but than again we are better safe then sorry and sufficient limited scope can take away a hell of a lot possible issues.

>> and a second address pool to manage.
> 
> Yes, but we do this all the time, it's not a big problem.
> 
>> ICMP can be sourced from a 'virtual interface'
>> and that is what all CPE I tested so far do, the current IETF drafts
>> cater for this, it's covered for by WAA-6/WPD-5 in
>> draft-ietf-v6ops-ipv6-cpe-router-03.
> 
> As soon as someone does firewalling on all his LAN prefixes with his
> CPE, I'd like to have a seperate IP to test 8-)

As soon as somebody starts firewalling he most likely also starts messing with the WAN address. It is largely implementation dependend where the ACL is placed logically....do you drop at the outside or control it when it goes out onto the LAN.

So far we have been asking vendors to pick a 'well known' address (like ::1) and at least make sure it responds to ICMPv6 echo, preferably this will be hardcoded in the firmware, but at least it should be the factory default to not mess with ICMP. 

> I have one such case right now in the v4 world, where the
> customer insists that he's not probed from our monitoring, but
> complains if the link is missing 8-) Beautiful 8-)

Yeah, somebody should come up with a standard for customers themselves.

> Yes, yes, check link state or interface counters instead, all this
> is possible, but it's not as nice as just sending a ping 8-)

You are talking ping for monitoring, go residential and all of a sudden you don't care about ICMP but you are actually running real management to push out configs and firmware updares (TR69) so you need to be able to actually access the modem.

>> I notice this requirement popping everytime and nobody can tell
>> me what the need is.
> 
> Since when is "Because I want to!" together with foot-stomping not
> reason enough 8-) ?


Well apparently it is enough because I keep explaining to vendors why we don't want a routable address on the outside and how the IETF draft we asked them to follow actually allows for it.

MarcoH


From bjorn at mork.no  Tue Dec 22 14:07:52 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 22 Dec 2009 14:07:52 +0100
Subject: Choosing an open source DHCPv6 client
Message-ID: <878wcvyx5j.fsf@nemi.mork.no>

Hello,

I'm wondering if I have missed something obvious, as I cannot really
find any open source DHCPv6 client which is either reasonably complete
or has some sort of development activity.  My main focus is PD support.

I've looked at these:

* KAME/WIDE wide-dhcpv6: http://sourceforge.net/projects/wide-dhcpv6/

 seems the most complete, but lacks reconfigure support and needs a few
 obvious bug fixes (most importantly: adding an unreacheable route for
 the delegated prefix to avoid routing loops)

 No(?) recent upstream activity, but the Debian maintainer is very
 responsive and has a few patches in his repository

* Dibbler: http://klub.com.pl/dhcpv6/
 
 seems to have had the highest recent activity, but the main (only?)
 developer has now announced that "Active development and non-critical
 bug fixing is on hold".  And the PD implementation is currently not
 useable (will assign a /48 to a single interface).

* RedHat dhcpv6: https://fedorahosted.org/dhcpv6/

 "No new development" announced, pointing to ISC dhcp version 4.1.0 as a
 replacement 

 Don't know the PD status.  The announcement is too discouraging to even
 bother checking.

* ISC: https://www.isc.org/software/dhcp

 Don't support PD (yet).  Will be interesting when it does.  But I'm not
 convinced the IPv4/IPv6 integration is a good idea.  It might help
 increase development resources though, which is definitely good.


* DHCPv6-linux: http://sourceforge.net/projects/dhcpv6-linux/

 Seems to be used by OpenWRT (in addition to Dibbler)?  No activity.  No
 PD.  No future.



My choice so far has been the KAME/WIDE wide-dhcpv6, as it is in a
useable state.  But I cannot help thinking that if anyone else is
actually using this, then it is strange that the obvious bugs haven't
been fixed.  Are there no open source DHCPv6-PD users, or is it just me
not finding the correct client?

And which client are the CPE vendors going to use?  With a few
exceptions, I can't imagine them all implementing DHCPv6 themselves.
That would be a nightmare...


Bj?rn

From shane at time-travellers.org  Tue Dec 22 14:59:00 2009
From: shane at time-travellers.org (Shane Kerr)
Date: Tue, 22 Dec 2009 14:59:00 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <878wcvyx5j.fsf@nemi.mork.no>
References: <878wcvyx5j.fsf@nemi.mork.no>
Message-ID: <1261490340.4204.1081.camel@shane-asus-laptop>

Bj?rn,

On Tue, 2009-12-22 at 14:07 +0100, Bj?rn Mork wrote:
> * ISC: https://www.isc.org/software/dhcp
> 
>  Don't support PD (yet).  Will be interesting when it does.  But I'm not
>  convinced the IPv4/IPv6 integration is a good idea.  It might help
>  increase development resources though, which is definitely good.

ISC DHCP 4.1 included prefix delegation:

https://www.isc.org/software/dhcp/new-features

This has been out for a year or so (apologies for the language which
makes it sound like it's "coming soon").

Also, the IPv4/IPv6 integration is not an artifact of good design, but
done because it was the simplest way to get IPv6 support in quickly.

We are planning on integrating DHCP into BIND 10, which is currently in
active development (on the DNS side at least).

For BIND 10 DHCP on the server side, we are planning on beginning with
DHCPv6 and then adding DHCPv4 later. Except for the weird BOOTP-inspired
packet format and weird things you have to do to send & receive packets
before you have an IP address, DHCPv4 behavior is actually a simplified
subset of DHCPv6 behavior. :) On the client side, we are looking at a
much simpler, lower footprint client than we have today - including one
that doesn't need to stay running all the time.

BTW, the main thing keeping us from doing DHCP development in BIND 10
(and in general) is lack of money. It seems very few people want to pay
for DHCP development - if you need specific features then let me know
and I'll see what we can do.

Cheers,

--
Shane


From bjorn at mork.no  Tue Dec 22 15:32:58 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 22 Dec 2009 15:32:58 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <1261490340.4204.1081.camel@shane-asus-laptop> (Shane Kerr's
	message of "Tue, 22 Dec 2009 14:59:00 +0100")
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
Message-ID: <874onjyt7p.fsf@nemi.mork.no>

Shane Kerr <shane at time-travellers.org> writes:
> On Tue, 2009-12-22 at 14:07 +0100, Bj?rn Mork wrote:
>> * ISC: https://www.isc.org/software/dhcp
>> 
>>  Don't support PD (yet).  Will be interesting when it does.  But I'm not
>>  convinced the IPv4/IPv6 integration is a good idea.  It might help
>>  increase development resources though, which is definitely good.
>
> ISC DHCP 4.1 included prefix delegation:
>
> https://www.isc.org/software/dhcp/new-features
>
> This has been out for a year or so (apologies for the language which
> makes it sound like it's "coming soon").

Ah, sorry for the misinformation.  I was briefly wading through the docs
trying to figure out how to configure it for a simple PD setup when I
hit this part of dhcp-options(5):

       option dhcp6.ia-pd string;

          The ia-pd option is manufactured by clients and servers to
          create a Prefix Delegation binding - to delegate an IPv6
          prefix to the client.  There is not yet any support for prefix
          delegation in this software, and this option is provided
          informationally only.

 
I stopped reading there, I'm afraid.  Just checked the 4.1.1rc1 version
released December 8, 2009 and the 4.2.0a1 version released December 4,
2009 and they both contain the same text in
{dhcp-4.1.1rc1,dhcp-4.2.0a1}/common/dhcp-options.5 

I guess it needs an update.  The reason I ended up in dhcp-options(5) is
that I was unable to find any PD information in dhclient.conf(5).  I see
now that it is mentioned in the dhclient(8) manual.  But I'm still in
the blue wrt howto convert this very simple wide-dhcpv6 config to ISC
dhclient config: 

interface ppp0
{
  send ia-pd 0;
  script "/etc/wide-dhcpv6/dhcp6c-script";
};
id-assoc pd {
        prefix-interface eth0 {
                sla-id 0;
        };
};



Do you happen to have a PD example configuration for dhclient?


> Also, the IPv4/IPv6 integration is not an artifact of good design, but
> done because it was the simplest way to get IPv6 support in quickly.
>
> We are planning on integrating DHCP into BIND 10, which is currently in
> active development (on the DNS side at least).

I guess you see the integration advantages.  I'm afraid I don't.  There
is also a DHCP server in FreeRADIUS nowadays.  Don't really see the
point of that either.

But I guess it will make the DDNS/DHCP connection easier.

> For BIND 10 DHCP on the server side, we are planning on beginning with
> DHCPv6 and then adding DHCPv4 later. Except for the weird BOOTP-inspired
> packet format and weird things you have to do to send & receive packets
> before you have an IP address, DHCPv4 behavior is actually a simplified
> subset of DHCPv6 behavior. :) On the client side, we are looking at a
> much simpler, lower footprint client than we have today - including one
> that doesn't need to stay running all the time.

simpler, lower footprint client sounds good.

> BTW, the main thing keeping us from doing DHCP development in BIND 10
> (and in general) is lack of money. It seems very few people want to pay
> for DHCP development - if you need specific features then let me know
> and I'll see what we can do.

I'm afraid that I don't have much interest in server development.  It
seems we've already paid for that, as our BRAS vendor has implemented
something that seems to work surprisingly well :-)


Bj?rn

From shane at time-travellers.org  Wed Dec 23 11:34:55 2009
From: shane at time-travellers.org (Shane Kerr)
Date: Wed, 23 Dec 2009 11:34:55 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <874onjyt7p.fsf@nemi.mork.no>
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<874onjyt7p.fsf@nemi.mork.no>
Message-ID: <1261564495.4204.1821.camel@shane-asus-laptop>

Bj?rn,

On Tue, 2009-12-22 at 15:32 +0100, Bj?rn Mork wrote:
> Shane Kerr <shane at time-travellers.org> writes:
> > On Tue, 2009-12-22 at 14:07 +0100, Bj?rn Mork wrote:
> >> * ISC: https://www.isc.org/software/dhcp
> >> 
> >>  Don't support PD (yet).  Will be interesting when it does.  But I'm not
> >>  convinced the IPv4/IPv6 integration is a good idea.  It might help
> >>  increase development resources though, which is definitely good.
> >
> > ISC DHCP 4.1 included prefix delegation:
> >
> > https://www.isc.org/software/dhcp/new-features
> >
> > This has been out for a year or so (apologies for the language which
> > makes it sound like it's "coming soon").
> 
> Ah, sorry for the misinformation.  I was briefly wading through the docs
> trying to figure out how to configure it for a simple PD setup when I
> hit this part of dhcp-options(5):
> 
>        option dhcp6.ia-pd string;
> 
>           The ia-pd option is manufactured by clients and servers to
>           create a Prefix Delegation binding - to delegate an IPv6
>           prefix to the client.  There is not yet any support for prefix
>           delegation in this software, and this option is provided
>           informationally only.
> 
>  
> I stopped reading there, I'm afraid.  Just checked the 4.1.1rc1 version
> released December 8, 2009 and the 4.2.0a1 version released December 4,
> 2009 and they both contain the same text in
> {dhcp-4.1.1rc1,dhcp-4.2.0a1}/common/dhcp-options.5 

Yikes! Okay, this has been fixed in our repository and should get pushed
out with the next release.

> I guess it needs an update.  The reason I ended up in dhcp-options(5) is
> that I was unable to find any PD information in dhclient.conf(5).  I see
> now that it is mentioned in the dhclient(8) manual.  But I'm still in
> the blue wrt howto convert this very simple wide-dhcpv6 config to ISC
> dhclient config: 
> 
> interface ppp0
> {
>   send ia-pd 0;
>   script "/etc/wide-dhcpv6/dhcp6c-script";
> };
> id-assoc pd {
>         prefix-interface eth0 {
>                 sla-id 0;
>         };
> };
> 
> 
> 
> Do you happen to have a PD example configuration for dhclient?

In doc/examples, there's 'dhcpd-dhcpv6.conf', which is a general
example of various kinds of syntax, static and dynamic prefix
delegation is in there.

We do intend to make an overall "PD howto" also.

> > Also, the IPv4/IPv6 integration is not an artifact of good design, but
> > done because it was the simplest way to get IPv6 support in quickly.
> >
> > We are planning on integrating DHCP into BIND 10, which is currently in
> > active development (on the DNS side at least).
> 
> I guess you see the integration advantages.  I'm afraid I don't.  There
> is also a DHCP server in FreeRADIUS nowadays.  Don't really see the
> point of that either.

BIND 10 is going to be a set of co-operating processes, a bit like
Postfix. So "integration" means a separate set of processes that uses
the same underlying mechanism as the DNS side. The advantage is that all
server-side daemons have a certain set of similar needs: configuration,
logging, and so on, and rather than re-invent this or have duplicate
code, we simply make it part of the same product. 

Since BIND 10 is modular, being "integrated" doesn't mean you have to
run everything. So if you really just want a DHCPv4 server, you only
carry the code and memory footprint necessary to run the DHCPv4 server,
not also the DHCPv6 server and the dynamic DNS server and so on.

--
Shane


From bjorn at mork.no  Wed Dec 23 12:24:46 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 23 Dec 2009 12:24:46 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <1261564495.4204.1821.camel@shane-asus-laptop> (Shane Kerr's
	message of "Wed, 23 Dec 2009 11:34:55 +0100")
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<874onjyt7p.fsf@nemi.mork.no>
	<1261564495.4204.1821.camel@shane-asus-laptop>
Message-ID: <87iqbyvsox.fsf@nemi.mork.no>

Shane Kerr <shane at time-travellers.org> writes:
> On Tue, 2009-12-22 at 15:32 +0100, Bj?rn Mork wrote:
>
>> Do you happen to have a PD example configuration for dhclient?
>
> In doc/examples, there's 'dhcpd-dhcpv6.conf', which is a general
> example of various kinds of syntax, static and dynamic prefix
> delegation is in there.

But that's the server configuration, surely?  I'm interested in how I
configure the *client* to request a PD and configure one or more
interfaces based on that.  The main problem is: How do I tell the client
that I want to allocate subnet X from the delegated /48 or /56 to
interface I, and subnet Y from the /48 or /56 to interface J?

Bonus for some way to trigger radvd to announce a subnet on one or more
interfaces, and extra bonus for some way to trigger dhclient based on
received RA flags (don't know if that is feasible as long as the
autoconf is done by the kernel?).


The dhclient example doesn't provide much info:

bjorn at nemi:/tmp$ cat dhcp-4.2.0a1/doc/examples/dhclient-dhcpv6.conf 
# Client configuration file example for DHCPv6

# The client side command to enable rapid-commit (2 packet exchange)
##send dhcp6.rapid-commit;

# name-servers and domain-search are requested by default.
# here is the way to request sip-servers-addresses too
also request dhcp6.sip-servers-addresses;

# Likely to be useful: the script path
script "/usr/local/etc/dhclient-script";


> We do intend to make an overall "PD howto" also.

That would be great.


This is as far I got:

ipv6-pppoe-1:~# ./dhclient -6 -v -d -P ppp0
Internet Systems Consortium DHCP Client 4.1.1rc1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Unsupported device type 512 for "ppp0"

If you did not get this software from ftp.isc.org, please
get the latest from ftp.isc.org and install that before
requesting help.

If you did get this software from ftp.isc.org and have not
yet read the README, please read it before requesting help.
If you intend to request help from the dhcp-server at isc.org
mailing list, please read the section on the README about
submitting bug reports and requests for help.

Please do not under any circumstances send requests for
help directly to the authors of this software - please
send them to the appropriate mailing list as described in
the README file.

exiting.






Bj?rn

From bjorn at mork.no  Wed Dec 23 15:57:35 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 23 Dec 2009 15:57:35 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <87iqbyvsox.fsf@nemi.mork.no> (=?utf-8?Q?=22Bj=C3=B8rn?=
	Mork"'s message of "Wed, 23 Dec 2009 12:24:46 +0100")
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<874onjyt7p.fsf@nemi.mork.no>
	<1261564495.4204.1821.camel@shane-asus-laptop>
	<87iqbyvsox.fsf@nemi.mork.no>
Message-ID: <87y6ktviu8.fsf@nemi.mork.no>

Bj?rn Mork <bjorn at mork.no> writes:

> Unsupported device type 512 for "ppp0"

Looks like this is an artifact of the code reuse.  Only Ethernet, Token
Ring and FDDI interfaces are supported by the common code.  Are there
any plans for PPP support?  That's an absolute requirement i found so
obvious I didn't even think of mentioning before.


Bj?rn

From shane at time-travellers.org  Wed Dec 23 16:57:00 2009
From: shane at time-travellers.org (Shane Kerr)
Date: Wed, 23 Dec 2009 16:57:00 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <87y6ktviu8.fsf@nemi.mork.no>
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<874onjyt7p.fsf@nemi.mork.no>
	<1261564495.4204.1821.camel@shane-asus-laptop>
	<87iqbyvsox.fsf@nemi.mork.no>  <87y6ktviu8.fsf@nemi.mork.no>
Message-ID: <1261583820.4204.2230.camel@shane-asus-laptop>

Bj?rn,

On Wed, 2009-12-23 at 15:57 +0100, Bj?rn Mork wrote:
> Bj?rn Mork <bjorn at mork.no> writes:
> 
> > Unsupported device type 512 for "ppp0"
> 
> Looks like this is an artifact of the code reuse.  Only Ethernet, Token
> Ring and FDDI interfaces are supported by the common code.  Are there
> any plans for PPP support?  That's an absolute requirement i found so
> obvious I didn't even think of mentioning before.

Hm... our restrictions on interface support come mostly from the IPv4
world. In that universe we have severe restrictions on what we can
support because we have to do funky things to send & receive packets. In
DHCPv6 one has the link-local addresses so one can use plain old
application layer-UDP.

BUT... we do need to get the hardware address (a MAC address in the case
of Ethernet) from the interface in DHCPv6. This address is needed to
make the client identifier (in most cases). Unfortunately there is no
standard way to do this - the API varies on each platform - and so we
have to code up support everywhere. Clearly the code is showing its age,
but it was written for the layer 2 stuff in use at the time. :)

It probably isn't a lot of work to extend this to support PPP, but since
PPP generally does its own IP assignment, there hasn't really been much
call for it.

Do you mind if I forward this to the dhcp-users list? It's probably a
better place for further discussion.

--
Shane


From gert at space.net  Wed Dec 23 17:13:33 2009
From: gert at space.net (Gert Doering)
Date: Wed, 23 Dec 2009 17:13:33 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <1261583820.4204.2230.camel@shane-asus-laptop>
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<874onjyt7p.fsf@nemi.mork.no>
	<1261564495.4204.1821.camel@shane-asus-laptop>
	<87iqbyvsox.fsf@nemi.mork.no> <87y6ktviu8.fsf@nemi.mork.no>
	<1261583820.4204.2230.camel@shane-asus-laptop>
Message-ID: <20091223161333.GK32226@Space.Net>

Hi,

On Wed, Dec 23, 2009 at 04:57:00PM +0100, Shane Kerr wrote:
> It probably isn't a lot of work to extend this to support PPP, but since
> PPP generally does its own IP assignment, there hasn't really been much
> call for it.

Isn't PPP (as in "DSL users, connected via PPPoE to their ISP") *the*
prototype application for DHCPv6-PD...?

> Do you mind if I forward this to the dhcp-users list? It's probably a
> better place for further discussion.

Where's this list, and how much volume does it have?  I'm not so much
interested in DHCP topics, but DHCPv6 PD is interesting...

Gert Doering
-- 
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 sthaug at nethelp.no  Wed Dec 23 17:25:09 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 23 Dec 2009 17:25:09 +0100 (CET)
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <20091223161333.GK32226@Space.Net>
References: <87y6ktviu8.fsf@nemi.mork.no>
	<1261583820.4204.2230.camel@shane-asus-laptop>
	<20091223161333.GK32226@Space.Net>
Message-ID: <20091223.172509.41702028.sthaug@nethelp.no>

> > Do you mind if I forward this to the dhcp-users list? It's probably a
> > better place for further discussion.
> 
> Where's this list, and how much volume does it have?  I'm not so much
> interested in DHCP topics, but DHCPv6 PD is interesting...

Here's the list:

     https://lists.isc.org/mailman/listinfo/dhcp-users

Have a look at the archives,

     https://lists.isc.org/pipermail/dhcp-users/

to get an idea of the volume.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From ipv6-ops+phil at spodhuis.org  Wed Dec 23 18:45:24 2009
From: ipv6-ops+phil at spodhuis.org (Phil Pennock)
Date: Wed, 23 Dec 2009 09:45:24 -0800
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <1261490340.4204.1081.camel@shane-asus-laptop>
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
Message-ID: <20091223174523.GA98426@redoubt.spodhuis.org>

On 2009-12-22 at 14:59 +0100, Shane Kerr wrote:
> For BIND 10 DHCP on the server side, we are planning on beginning with
> DHCPv6 and then adding DHCPv4 later. Except for the weird BOOTP-inspired
> packet format and weird things you have to do to send & receive packets
> before you have an IP address, DHCPv4 behavior is actually a simplified
> subset of DHCPv6 behavior. :)

*snert*  No.

In an ISP environment, dealing with RAIO support, it quickly became
clear how screwed up DHCPv4 relay support is.  DHCPv6 is clean and
unambiguous (controls for, eg, whether or not the authoritative server's
IP address should be passed onto the client).  The relevant areas in
DHCPv4 show battle-scars from vendors fighting to avoid having to do The
Right Thing.

I wish DHCPv4 were as clean, secure and unambiguous as DHCPv6.

-Phil

From shane at time-travellers.org  Wed Dec 23 20:08:22 2009
From: shane at time-travellers.org (Shane Kerr)
Date: Wed, 23 Dec 2009 20:08:22 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <20091223174523.GA98426@redoubt.spodhuis.org>
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<20091223174523.GA98426@redoubt.spodhuis.org>
Message-ID: <1261595302.4204.2426.camel@shane-asus-laptop>

Phil,

On Wed, 2009-12-23 at 09:45 -0800, Phil Pennock wrote:
> On 2009-12-22 at 14:59 +0100, Shane Kerr wrote:
> > For BIND 10 DHCP on the server side, we are planning on beginning with
> > DHCPv6 and then adding DHCPv4 later. Except for the weird BOOTP-inspired
> > packet format and weird things you have to do to send & receive packets
> > before you have an IP address, DHCPv4 behavior is actually a simplified
> > subset of DHCPv6 behavior. :)
> 
> *snert*  No.
> 
> In an ISP environment, dealing with RAIO support, it quickly became
> clear how screwed up DHCPv4 relay support is.  DHCPv6 is clean and
> unambiguous (controls for, eg, whether or not the authoritative server's
> IP address should be passed onto the client).  The relevant areas in
> DHCPv4 show battle-scars from vendors fighting to avoid having to do The
> Right Thing.
> 
> I wish DHCPv4 were as clean, secure and unambiguous as DHCPv6.

Ah, our relay support is quite basic. Something we hope to fix as
well... but it is lowish priority as most people use appliances to do
DHCP relaying rather than software-only solutions like our software.

And yes, DHCPv6 is a work of beauty compared to DHCPv4. Probably because
so many people tried to kill it!

--
Shane


From bjorn at mork.no  Mon Dec 28 11:03:34 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 28 Dec 2009 11:03:34 +0100
Subject: Choosing an open source DHCPv6 client
In-Reply-To: <1261583820.4204.2230.camel@shane-asus-laptop> (Shane Kerr's
	message of "Wed, 23 Dec 2009 16:57:00 +0100")
References: <878wcvyx5j.fsf@nemi.mork.no>
	<1261490340.4204.1081.camel@shane-asus-laptop>
	<874onjyt7p.fsf@nemi.mork.no>
	<1261564495.4204.1821.camel@shane-asus-laptop>
	<87iqbyvsox.fsf@nemi.mork.no> <87y6ktviu8.fsf@nemi.mork.no>
	<1261583820.4204.2230.camel@shane-asus-laptop>
Message-ID: <87fx6vbekp.fsf@nemi.mork.no>

Shane Kerr <shane at time-travellers.org> writes:

> Hm... our restrictions on interface support come mostly from the IPv4
> world. In that universe we have severe restrictions on what we can
> support because we have to do funky things to send & receive packets. In
> DHCPv6 one has the link-local addresses so one can use plain old
> application layer-UDP.

Yes, it's completely different.  Which is why I wondered if the combined
DHCP/DHCPv6 client is a good idea.  I can imagine that the timers/event
code could be reused, but that's about all.  IMHO.

> BUT... we do need to get the hardware address (a MAC address in the case
> of Ethernet) from the interface in DHCPv6. This address is needed to
> make the client identifier (in most cases). Unfortunately there is no
> standard way to do this - the API varies on each platform - and so we
> have to code up support everywhere. Clearly the code is showing its age,
> but it was written for the layer 2 stuff in use at the time. :)

I believe the requirements for a DHCPv6 DUID are specifically written to
allow DHCPv6 on any type of interface.

> It probably isn't a lot of work to extend this to support PPP, but since
> PPP generally does its own IP assignment, there hasn't really been much
> call for it.

For IPv4, sure.  DHCPv6 is just as interesting (if not more) on PPP as
it is on Ethernet.

We're probably going to require PPP for IPv6, at least in the beginning,
due to the L2 design we have between our BRAS's and the customers, and
the currently limited support for IPv6 based L2 magic.

And DHCPv6-PD is also going to be a requirement.  We might use SLAAC for
the WAN link, but we're not going to support SLAAC-only customers.  The
WAN prefix will most likely be filtered to allow management access
only.  The customers will have to select a source address from their
DHCPv6 delegated prefix to actually reach anything useful.

So PPP + DHCPv6-PD it is.

I'm quite sure we can't be the only ISP thinking like this...

> Do you mind if I forward this to the dhcp-users list? It's probably a
> better place for further discussion.

I don't mind, but I probably won't follow it.  The dhcp-users is is one
of the mailing lists I'm subscribed to, but rarely have time to read...

As with Gert, I'm really not that interested in DHCP (for IPv4)
discussions right now.  So maybe we can continue the DHCPv6-PD
discussion here as long as no-one complains about it being operational
off-topic?  My impression is that most IPv6 related topics are accepted
(and wanted?) here.



Bj?rn

From thedarkone at list.ru  Wed Dec 30 22:25:45 2009
From: thedarkone at list.ru (The Dark One)
Date: Thu, 31 Dec 2009 00:25:45 +0300
Subject: anycast address as deault router
Message-ID: <E1NQ637-000319-00.thedarkone-list-ru@f252.mail.ru>

Experts,
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?
If it does makes sense, is it also possible to have the routers advertise that anycast address in their RA?
Thanks.



From nick-lists at netability.ie  Wed Dec 30 22:29:42 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Wed, 30 Dec 2009 21:29:42 +0000
Subject: anycast address as deault router
In-Reply-To: <E1NQ637-000319-00.thedarkone-list-ru@f252.mail.ru>
References: <E1NQ637-000319-00.thedarkone-list-ru@f252.mail.ru>
Message-ID: <4B3BC646.8050700@netability.ie>

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?
> If it does makes sense, is it also possible to have the routers
> advertise that anycast address in their RA?

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.

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

Nick

From mksmith at adhost.com  Wed Dec 30 22:33:22 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 30 Dec 2009 13:33:22 -0800
Subject: anycast address as deault router
In-Reply-To: <4B3BC646.8050700@netability.ie>
References: <E1NQ637-000319-00.thedarkone-list-ru@f252.mail.ru>
	<4B3BC646.8050700@netability.ie>
Message-ID: <17838240D9A5544AAA5FF95F8D520316074E7A2C@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 Nick Hilliard
> Sent: Wednesday, December 30, 2009 1:30 PM
> To: The Dark One
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: anycast address as deault router
> 
> 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?
> > If it does makes sense, is it also possible to have the routers
> > advertise that anycast address in their RA?
> 
> 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.
> 
> By all means try it out, but when it refuses to work, take a look at
> RFC2462 (section 5.4).
> 
> Nick

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.

Regards,

Mike