Looking for contributors

[Brian E Carpenter]

There's an effort to write a free, open-source, on-line book for the benefit of 
IPv6 practitioners.

Who's going to write it? IPv6 practitioners. You.

https://github.com/becarpenter/book6 now has a (very small) amount of general 
text, but we're waiting for more collaborators and more text from the community.

As the README says, "The intention is a practical introduction to IPv6 for technical 
people, kept up to date by active practitioners."

There's a little preliminary content in sections 1 and 8, but still 6 empty 
chapters...

Discussions and issues can be raised on GitHub but PRs with new text would be 
even better.

Send me your github ID if interested.
  
Regards

Brian

Re: Multiaddressing Intent and Practicality

[Brian E Carpenter]

Hi Jason,

You might consider taking this discussion also to v6...@ietf.org. I guarantee 
you would get a full set of answers to choose from ;-). More below...

On 06-Aug-22 00:16, Jason Iannone wrote:

This is a question about multihomed systems, systems attached to multihomed 
networks, or systems providing services to both public and private resources.

I'm considering a scenario that looks like this[1], where a multihomed HQ has 
unique PA /48s and delegates them throughout the enterprise. The HQ network 
admins deploy a pair of /56s per remote site, each prefix coming from a 
different provider. This may be a bad assumption and I'm asking for help.

What does a public service hosted at site 4 look like? If I query the  
record, do I get a pair of addresses and DNS round robin them in the classic 
way? Are there well defined best practices for this kind of thing to ensure 
availability? How does this support resilient services? I want my webserver to 
be accessible during ISP failure. DNS round robin doesn't do that. It requires 
intervention to update the record and restore service.


The classical answer is get your own PI /48 from the RIR and have both ISPs 
announce it. The alternative is to persuade each ISP to announce both the PA 
/48s. If they are doing ingress filtering 
(https://www.rfc-editor.org/info/bcp84) they have to allow each other's /48.
 

What if I change the diagram a bit, like this[2]? In this case the Private WAN 
subnet is not publicly advertised. My remote sites want to talk to the web 
server. My web server also wants to be publicly accessible. My web server now 
has two addresses and two  records, one public and one private. Is this how 
IPv6 multiaddressing is intended to be used?


Split horizon DNS is pretty common for this sort of reason. You can consider 
using a ULA prefix (RFC 4193) for internal use, although it isn't required.



What is the routing behavior for source address selection in the second case? 


Longest match should work out all right.

How does the web server know to talk to the internet using its public address and site to site using its private address for connections it initiates? 


RFC 6724 should take care of that, if you set the precedence entries up 
correctly. How to do that is o/s dependent, unfortunately. (Except that there's 
a current IETF discussion on making that work properly with ULA addresses: 
https://www.ietf.org/archive/id/draft-ietf-v6ops-ula-00.html)


Are these things clearly defined and figured out in literature and BCPs? Do we 
really rely on host based routing and security in IPv6 rather than transit 
nodes?


I'm not sure what you mean there, but IPv6 does *not* rely on NAT. Firewalls 
and ACLs work of course.

Hope this helps, but probably some other people will amplify.

Regards
  Brian Carpenter



[1]https://i.imgur.com/Jzvj2sz.png 

[2]https://i.imgur.com/XB416tT.png 

Jason

Re: Prefix delegation to sub nets

[Brian E Carpenter]

I suggest raising that on home...@ietf.org
https://datatracker.ietf.org/wg/homenet/about/

Regards
   Brian Carpenter

On 03-Jul-21 07:19, Doug Hardie wrote:
> I have been working my way through the RFCs and it appears HNCP might be the 
> solution.  However, both of those implementations require the prefix from the 
> ISP be configured by hand.  That is not viable in situations where a dynamic 
> IP address is provided.  I suspect that HNCP and DHCP6 will need to be 
> integrated for that.  
> 
> -- Doug
> 
>> On 28 June 2021, at 03:00, Chriztoffer Hansen  wrote:
>>
>> You could try https://github.com/jech/shncpd or
>> https://github.com/sbyx/hnetd/, though the last update to those
>> repositories was 2017-2018...
>>
>>
>> On Mon, 28 Jun 2021 at 11:10, Brian Carpenter
>>  wrote:
>>>
>>> Is HNCP available for the various Linux distros?
>>> If not, it has to be PD, I think.
>>>
>>> Regards,
>>>Brian Carpenter
>>>    (via tiny screen & keyboard)
>>>
>>> On Mon, 28 Jun 2021, 20:51 Ole Troan,  wrote:
>>>>
>>>>
>>>>
>>>>> On 27 Jun 2021, at 23:07, Brian E Carpenter  
>>>>> wrote:
>>>>>
>>>>> That doesn't work. B needs to get its own /64 prefix(es) from A via 
DHCPv6-PD (https://www.rfc-editor.org/info/rfc8415). That's what DHCPv6-PD is 
for. So A will indeed need to be a DHCPv6 server on its downstream interfaces.
>>>>
>>>> To the extent it matters, it’s not what DHCP PD was designed 
for.
>>>>
>>>> HNCP does internal prefix assignment in a network.
>>>>
>>>> Now, if you were to use DHCP PD for this, I would recommend a single 
PD server in the network (on A).  DHCP PD clients on all internal routers. 
Either DHCP relays or more simply each internal router PD client configured 
with the address of the PD server directly. Then an IGP to advertise prefixes.
>>>>
>>>> The PD clients should request individual /64s for each of their downstream 
>>>> interfaces.
>>>>
>>>> This scheme does not work great in networks with loops or multiple routers 
>>>> on a link. If using DHCP relays you manually have to make a spanning tree.
>>>> And you risk links being assigned multiple prefixes.
>>>>
>>>> HNCP solves all of this.
>>>>
>>>> Cheers
>>>> Ole
>>
>>
>>
>> -- 
>> Chriztoffer
>>
> 

Re: Prefix delegation to sub nets

[Brian E Carpenter]

> Unfortunately there are ISPs that are giving out /64 or even smaller.  The 
> claim is that is only temporary, but no indication of when that would 
stop.

They need to be named and shamed. We have that problem with 3GPP operators in 
particular.

Regards
   Brian Carpenter

On 28-Jun-21 10:39, Doug Hardie wrote:
>> On 27 June 2021, at 14:07, Brian E Carpenter  
>> wrote:
>>
>> Please don't look at ancient drafts. Look at the homenet architecture RFC:
>> https://www.rfc-editor.org/info/rfc7368
> 
> I went looking when I saw the date on the draft and found the RFC.
> 
>>
>> Definitively, using any prefix longer than /64 *will not work*. The /64 has 
>> been carved in stone for many years; that's *why* you get a /48 or /56 
>> from the ISP.
> 
> Unfortunately there are ISPs that are giving out /64 or even smaller.  The 
> claim is that is only temporary, but no indication of when that would 
stop.
> 
>>
>>> The B router receives the prefix via SLAAC and creates its own EUI-64 
address. However, that router needs to create a smaller subnet...
>>
>> That doesn't work. B needs to get its own /64 prefix(es) from A via 
>> DHCPv6-PD (https://www.rfc-editor.org/info/rfc8415). That's what DHCPv6-PD 
>> is for. So A will indeed need to be a DHCPv6 server on its downstream 
>> interfaces.
> 
> The issue is though how does the server get the prefix the client received?  
> I suspect the script and restart of the server is probably the only 
way at this tim.
> 
>>
>> If you run OpenWrt on A, this is apparently supported. See 
>> https://openwrt.org/docs/guide-user/network/ipv6/dhcp6c#example. But I have 
>> no experience with that.
>>
>> Regards
>>   Brian Carpenter
>>
>> On 28-Jun-21 08:32, Doug Hardie wrote:
>>>
>>> -- Doug
>>>
>>>> On 27 June 2021, at 12:41, Michael Chang >>> <mailto:thenewm...@gmail.com>> wrote:
>>>>
>>>> If you actually want that topology, I think in practice the downstream 
>> router (B) must be at least a /64; if you got a /48 then I think you can set 
>> up A with /56s, which it can use to sub-allocate a /64 to B.
>>>>  
>>>> https://tools.ietf.org/id/draft-ietf-homenet-arch-01.html 
>>>> <https://tools.ietf.org/id/draft-ietf-homenet-arch-01.html>
>>>>
>>>> The config in section 7.2 of 
>>>> https://wiki.archlinux.org/title/IPv6#Prefix_delegation_(DHCPv6-PD) 
>>>> <https://wiki.archlinux.org/title/IPv6#Prefix_delegation_(DHCPv6-PD)> 
>>>> might be what you're looking for? (See the note 
about `sla-len`.)
>>>
>>> The addresses could be done that way.  However, the issue still remains, 
>>> how does router B distribute the prefix?  Is using a dual dhcp6c - dhcp6s 
>>> the way to go and how does dhcp6s get the prefix from dhcp6c?
>>>
>>>>
>>>>
>>>> On Sun, Jun 27, 2021 at 12:05 PM Kristian McColm 
>>>> mailto:kristian.mcc...@rci.rogers.com>> 
>>>> wrote:
>>>>
>>>>RFC 5375 advises against prefixes longer than /64. 
>>>>
>>>>https://datatracker.ietf.org/doc/html/rfc5375#appendix-B.2 
>>>> <https://datatracker.ietf.org/doc/html/rfc5375#appendix-B.2>
>>>>
>>>>A /48 gives you 65535 /64’s, why not use some of them?
>>>>
>>>>
>>>> --
>>>>*From:* 
>>>> ipv6-ops-bounces+kristian.mccolm=rci.rogers@lists.cluenet.de 
>>>> <mailto:rci.rogers@lists.cluenet.de> 
>>>> >>> <mailto:rci.rogers@lists.cluenet.de>> on behalf of

Re: Prefix delegation to sub nets

[Brian E Carpenter]

Please don't look at ancient drafts. Look at the homenet architecture RFC:
https://www.rfc-editor.org/info/rfc7368

Definitively, using any prefix longer than /64 *will not work*. The /64 has 
been carved in stone for many years; that's *why* you get a /48 or /56 
from the ISP.

> The B router receives the prefix via SLAAC and creates its own EUI-64 
> address. However, that router needs to create a smaller subnet...

That doesn't work. B needs to get its own /64 prefix(es) from A via DHCPv6-PD 
(https://www.rfc-editor.org/info/rfc8415). That's what DHCPv6-PD is for. So A 
will indeed need to be a DHCPv6 server on its downstream interfaces.

If you run OpenWrt on A, this is apparently supported. See 
https://openwrt.org/docs/guide-user/network/ipv6/dhcp6c#example. But I have no 
experience with that.

Regards
   Brian Carpenter

On 28-Jun-21 08:32, Doug Hardie wrote:
> 
> -- Doug
> 
>> On 27 June 2021, at 12:41, Michael Chang > > wrote:
>>
>> If you actually want that topology, I think in practice the downstream 
router (B) must be at least a /64; if you got a /48 then I think you can set up 
A with /56s, which it can use to sub-allocate a /64 to B.
>>  
>> https://tools.ietf.org/id/draft-ietf-homenet-arch-01.html 
>> 
>>
>> The config in section 7.2 of 
>> https://wiki.archlinux.org/title/IPv6#Prefix_delegation_(DHCPv6-PD) 
>>  might 
>> be what you're looking for? (See the note about `sla-len`.)
> 
> The addresses could be done that way.  However, the issue still remains, how 
> does router B distribute the prefix?  Is using a dual dhcp6c - dhcp6s the way 
> to go and how does dhcp6s get the prefix from dhcp6c?
> 
>>
>>
>> On Sun, Jun 27, 2021 at 12:05 PM Kristian McColm 
>> mailto:kristian.mcc...@rci.rogers.com>> 
>> wrote:
>>
>> RFC 5375 advises against prefixes longer than /64. 
>>
>> https://datatracker.ietf.org/doc/html/rfc5375#appendix-B.2 
>> 
>>
>> A /48 gives you 65535 /64’s, why not use some of them?
>>
>> 
>> --
>> *From:* ipv6-ops-bounces+kristian.mccolm=rci.rogers@lists.cluenet.de 
>>  
>> > > on behalf of Doug Hardie 
>> mailto:bc...@lafn.org>>
>> *Sent:* Sunday, June 27, 2021 2:54:01 PM
>> *To:* ipv6-ops@lists.cluenet.de  
mailto:ipv6-ops@lists.cluenet.de>>
>> *Subject:* Prefix delegation to sub nets
>>  
>> I am trying to setup an IPv6 environment.  There is a primary 
router (A) that receives a /48 prefix via DHCP6 from the ISP. That router 
configures itself properly via dhcp6c.  It also creates 2 LAN /64 prefixes and 
creates EUI-64 addresses on the two LAN interfaces.  One of those interfaces is 
connected to a second router (B), among other devices.  The B router receives 
the prefix via SLAAC and creates its own 
EUI-64 address.  However, that router needs to create a smaller subnet, /72, 
and distribute it to the devices on that LAN.  I have not been able to figure 
out how to make that happen.
>>
>> Clearly, manual configuration would work, but the prefix received from 
>> the ISP can change which would raise havoc with the network.  I 
suspect that dhcp6s needto be run alongside dhcp6c on router B and then the 
other devices run dhcp6c.  However, I don't see how to get the prefix that 
dhcp6c receives on router B to the dhcp6s process on router B.  I believe I am 
missing something, but haven't been able to find it.  Thanks,
>>
>> -- Doug
>>
>>
>>
>>
>>
>> 
>> 

Comcast IPv6 routing

[Brian E Carpenter]

Anybody here from Comcast who might be interested by a strange v6 (and v4) 
route within the USA? Contact me off list.

Regards
   Brian Carpenter

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Brian E Carpenter]

At the risk of repeating myself, if ops people like this approach
then they need to engage in constructive discussion of it in the IETF.

No need for a travel budget, especially now.
https://www.ietf.org/mailman/listinfo/ipv6

Regards
   Brian

On 02-Apr-20 23:10, otr...@employees.org wrote:
>> DHCPv6 took itself out of the running when it failed to provide the
>> default gateway to its clients.
> 
> I just posted an updated version of what was the "Universal RA option" draft.
> It is now the "Universal IPv6 Configuration Option", which includes support 
> for default gateway in DHCPv6.
> 
> https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1
> 
> Best regards,
> Ole.
> 

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Brian E Carpenter]

On 31-Mar-20 23:17, Mark Tinka wrote:
> 
> 
> On 31/Mar/20 12:09, sth...@nethelp.no wrote:
> 
>> Note that there have been multiple requests for DHCPv6 to do this but
>> every attempt has been shot down.
> 
> Yep - thankfully, we have an option.
> 
> Operating two address assignment protocols is just silly.
> 
> At my house, I don't even bother with DHCPv6 for DNS. I just use the
> IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about
> done with the purist madness around this.

There's purism (which I don't understand) and there's also historical
baggage that is incredibly hard to get rid of. As I have reminded from
time to time, SLAAC was designed and implemented for IPv6 *before* DHCP
became a proven technology for IPv4 (i.e. many of us were still running
around manually assigning IPv4 addresses to newly installed Suns and
NCDs and the like). DHCPv6 was an afterthought.

Unfortunately, the purism has made it impossible to have a rational
discussion about engineering our way out of this historical duplication.

On 01-Apr-20 05:01, Gert Doering wrote:

...
> As soon as you have a larger routed network, mDNS falls short, and 
> (unless you have a windows domain) there are no existing mechanisms
> to put a SLAAC v6 address into DNS...

I think there's no *deployed* mechanism. DynDNS is said to work in the
lab. There's also some hope that DNS-SD will alleviate this problem, 
but only if it gets deployed.

> Yes, thanks, IETF.  Well done.

It's not because nobody has tried. But the bridge between theory and
operations seems to be hard to cross.

On 01-Apr-20 07:21, James R Cutler wrote:

...
> Wouldn’t it be more cost effect in the long term to simply make SLAAC and 
> DHCPv6 cooperative and complementary attributes of end-to-end networking? 

Well, duh. What we need is more people with real operational smarts
able to spend a lot of time and patience in the IETF. Yes, I know
why that is hard. (I had operation smarts once; no longer.) But that
is the only way we we can get a pragmatic approach into RFC text.

Don't worry about the travel budget, because the IETF is going to
have to do much more of its work remotely for the next couple of years
anyway. But the time and patience investment is substantial.

Stay well,
   Brian Carpenter

Re: Why used DHCPv6 when RA has RDNSS and DNSSL?

[Brian E Carpenter]

It seems that the router must be setting both the A bit (use SLAAC) and the M 
bit (use DHCPv6). So the host is obeying both. There's no real harm in it, in 
most circumstances.

Fixing the ambiguity about what hosts should do about this has often been 
discussed in the IETF but there's never really been evidence that it's worth 
doing.

Regards
   Brian Carpenter

On 31-Mar-20 13:30, Roger Wiklund wrote:
> Hi
> 
> I played around with IPv6 on my Mac today (Mac OS Catalina) and I noticed 
> that besides the IP from DHCPv6 (dynamic) it's also generating two other 
> addresses.
> 
> ether aa:bb:cc:dd:ee:ff
> inet6 fe80::1cad:944f:df4a:d123%en0 prefixlen 64 secured scopeid 0x7
> inet6 2001:123:44:55:1a:f346:1bef:b88a prefixlen 64 autoconf secured
> inet6 2001:123:44:55:20ac:49d2:68c5:595b prefixlen 64 autoconf temporary
> inet6 2001:123:44:55::101 prefixlen 64 dynamic
> 
> I don't really know that the "secured" address is used for TBH (both autoconf 
> are randomized and not based on the MAC)
> The temporary address is used for outgoing connections and is changed every 
> so often.
> The dynamic address if from my DHPv6 server.
> 
> I think Windows has the same behaivour.
> 
> This got me thinking, if the temporary address is used as the outgoing source 
> address, this gives me even less incentive to use DHCPv6. Especially since my 
> Juniper SRX supports RDNSS via RA: https://tools.ietf.org/html/rfc8106
> 
> set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 
> 2001:4860:4860:: lifetime 3600
> set protocols router-advertisement interface ge-0/0/0.20 dns-server-address 
> 2001:4860:4860::8844 lifetime 3600
> set protocols router-advertisement interface ge-0/0/0.20 prefix 
> 2001:123:44:55::/64
> 
> When I read DHCPv6 vs SLAAC it often boils down to "control" but I don't see 
> the need to allocate a dynamic address if the autogenerated are used. For 
> client's you dont really have any inbound connections unless it's a support 
> case.
> 
> What's your view on this?
> 
> Thanks!

Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Brian E Carpenter]

Hi Michael,

On 26-Oct-19 12:33, Michael Sturtz wrote:
> The problem with non-routable private ULA addressing is most vendor equipment 
> doesn't support having a SLAAC or DHCP6 dynamic routable address and a static 
> ULA address.

Yes. But that is the vendors' fault for not doing what the RFCs recommend. I 
don't really see how another RFC can fix that.

> 
> For simple home networks I suppose we could have a RFC that proposes the FE80 
> address space be used as the "static" address space for SOHO server 
> addressing and locating such as local DNS or single server environments

By "simple" you mean with no interior routers, I guess. Yes, that's what I 
have; no RFC needed, just a well designed CE. Here's how it looks from Windows 
(and pretty much the same from Linux), just some magic numbers obscured:

Ethernet adapter Ethernet 4:

   Connection-specific DNS Suffix  . : fritz.box
   Description . . . . . . . . . . . : ASIX AX88772B USB2.0 to Fast Ethernet 
Adapter #2
   Physical Address. . . . . . . . . : 
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 
2406:e002::9301:80b2:5c79:2266:e431(Preferred)
   IPv6 Address. . . . . . . . . . . : 
fd63:45eb:dc14:0:80b2:5c79:2266:e431(Preferred)
   Temporary IPv6 Address. . . . . . : 
2406:e002::9301:243c:2e79:2618:e284(Preferred)
   Temporary IPv6 Address. . . . . . : 
fd63:45eb:dc14:0:243c:2e79:2618:e284(Preferred)
   Link-local IPv6 Address . . . . . : fe80::80b2:5c79:2266:e431%7(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.178.30(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, 22 October, 2019 15:07:41
   Lease Expires . . . . . . . . . . : Tuesday, 5 November, 2019 13:43:40
   Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%7
   192.168.178.1
   DHCP Server . . . . . . . . . . . : 192.168.178.1
   DHCPv6 IAID . . . . . . . . . . . : 
   DHCPv6 Client DUID. . . . . . . . : 
   DNS Servers . . . . . . . . . . . : fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
   192.168.178.1

> or the end user equipment could just assume that it would be "static" given 
> the common use of EUI-64 for the /64 portion (Windows excepted). 

EUI-64 is legacy at this point. You get stable addresses using a locally 
generated stable ID, 80b2:5c79:2266:e431 in the above case. Again - the RFCs 
already have all this; tell your vendors what you want, repeatedly and loudly, 
is all I can suggest.
 
> Right now, with the way it actually works in the field it is very disruptive 
> every time the /64 is renumbered by the ISP  In my experience this happens 
> way too often. 

Yes, we all agree about that. That's exactly why Fernando has written his 
draft. (Of course the ISP should be giving you a /48 or /56, but that's another 
existing RFC.)

> An end user should not have to go around and reboot devices, hunt around for 
> the new printer IP and so on just because the ISP caused a renumber of their 
> automatically assigned /64.  With SOHO networks which are the vast majority 
> of end user networks we can't make it painful to use IPv6.  Even novice users 
> can navigate the web UI of a home router and assign a static IP address to 
> their network printer / scanner / copier etc. and it is very common to do 
> this with IPv4.  The random ISP renumbering completely breaks that whole use 
> case. Given the very long IPv6 addresses, DNS (name resolution) becomes very 
> important for most end users.  Currently, this works fine on IPv4 because of 
> NAT, PAT & RFC1918.  We don't have an operational answer for this on IPv6 at 
> all.  For sites such as this I routinely get trouble tickets of random 
> degraded connectivity that can be traced back to an ISP renumber event and 
> one or more pieces of equipment didn't handle the renumber and could not 
> connect to something else on the network or could not connect to something on 
> the IPv6 internet.

Again, exactly why Fernando has written his draft. I notice that my Canon 
printer has fe80::2bb:c1ff:fe99:cd6 as well as 192.168.178.23. That's OK for a 
network with no interior routers. However, it looks as if the Canon utilities 
use IPv4. But in general IPv6 works well with this set up, even when my ISP has 
a glitch and I get flash-renumbered, as happened earlier this week.

Regards
Brian

> 
> 
> 
> -Original Message-
> From: Brian E Carpenter  
> Sent: Friday, October 25, 2019 4:02 PM
> To: Matthew Huff ; Nick Hilliard ; Michael 
> Sturtz 
> Cc: ipv6-ops@lists.cluenet.de; Fernando Gont ; Gert 
> Doering 
> Subject: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
> 
> On 26-Oct-19 04:19, Matthew Huff wrote:
>> Th

static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Brian E Carpenter]

On 26-Oct-19 04:19, Matthew Huff wrote:
> This is part of one of the many reasons corporate acceptance of IPv6 is so 
> low. The IPv6 design appears to be oriented toward residential, ISP, and 
> public wifi usages, with little care to corporate needs. Not only is static 
> IPs desired, but in many cases required by regulation (Auditing, access, 
> etc...). 

That is *not* a design issue. It's an ISP business practice issue, and it's why 
the RIRs have for a long time been assigning /48s for enterprises that want 
them.

> Things like DHCPv6 not supporting DNS server announcements is a good example 
> (it's available recently, but not across all platforms). Private address may 
> be a great thing for residential / public wifi, etc... but must be disabled 
> in many, if not all, corporate environments.

Absolutely. They are a recommended default for the consumer market but I would 
expect most corporate deployments to disable them.

> Also, we have found that many software vendors certify their products for 
> IPv6, but as soon as the PR release is done, their devs no longer test with 
> IPv6 and their tech support almost always recommend disabling it the first 
> time you open a ticket.

Again, it's a business issue over which paying customers have much more 
influence that anyone else, but only if they make it a commercial issue.

Progress will only come as more and more people stop putting IPv6 in the "too 
hard" basket. I really do understand that for people running actual services 
this is not a trivial thing, but it's a real chicken/egg situation, 
unfortunately. But the signs are good at last.

Regards
Brian Carpenter

> 
> -Original Message-
> From: ipv6-ops-bounces+mhuff=ox@lists.cluenet.de 
>  On Behalf Of Nick Hilliard
> Sent: Friday, October 25, 2019 11:10 AM
> To: Michael Sturtz 
> Cc: ipv6-ops@lists.cluenet.de; Gert Doering ; Fernando Gont 
> 
> Subject: Re: ipv6-ops Digest, Vol 159, Issue 1
> 
> Michael Sturtz wrote on 25/10/2019 16:03:
>> This sort of operational nonsense will limit the wider acceptance of 
>> IPv6!  I am responsible research and for the documentation and 
>> implementation of IPv6 for a Fortune 200 company.  We have locations 
>> worldwide.  The allocation of unstable end network addresses 
>> complicates the deployment and support of IPv6.
> most service providers view this as a commercial issue rather than a protocol 
> issue.  This is just an observation, btw.
> 
> Nick
> 

Re: ULA [was: ipv6-ops Digest, Vol 159, Issue 1]

[Brian E Carpenter]

On 25-Oct-19 01:07, Fernando Gont wrote:
> On 23/10/19 14:53, Brian E Carpenter wrote:
>> On 24-Oct-19 03:57, David Forrest wrote:
>>> My ULA is a /48 while Charter Spectrum only gives me a /64.  Then I lose my 
>>> network info.
>>
>> Huh? You will simply use a /64 within the ULA /48. However, you should only 
>> generate the ULA prefix once and store it in stable storage; that should be 
>> a feature of your CE. Then you never change the ULA prefix.
> 
> "MAY be a feature..." ;-) many (most?) will not even know about ULAs.  :-(

Right; one reason I'm hapy that my ISP (in NZ) sent me a FritzBox.

I'd be happier still if https://tools.ietf.org/html/rfc7084
made ULA support a MUST instead of a SHOULD.

   Brian

ULA [was: ipv6-ops Digest, Vol 159, Issue 1]

[Brian E Carpenter]

On 24-Oct-19 03:57, David Forrest wrote:
> My ULA is a /48 while Charter Spectrum only gives me a /64.  Then I lose my 
> network info.

Huh? You will simply use a /64 within the ULA /48. However, you should only 
generate the ULA prefix once and store it in stable storage; that should be a 
feature of your CE. Then you never change the ULA prefix.

Regards
   Brian Carpenter
>  
> Amicalement,
> Dave
> 
> Maple Park Development
> Linux Systems Integration
> http://www.maplepark.com/
> 
> 
> 
> On Wed, Oct 23, 2019 at 9:35 AM Kristian McColm 
> mailto:kristian.mcc...@rci.rogers.com>> 
> wrote:
> 
> Isn't that what ULA's are for?
> 
> 
> --
> *From:* ipv6-ops-bounces+kristian.mccolm=rci.rogers@lists.cluenet.de 
>  
>  > on behalf of Michael Sturtz 
> 
> *Sent:* October 23, 2019 10:26 AM
> *To:* ipv6-ops@lists.cluenet.de  
> mailto:ipv6-ops@lists.cluenet.de>>
> *Subject:* RE: ipv6-ops Digest, Vol 159, Issue 1
>  
> I have found more problems with the DHCPv6-PD.  The issue is on many home 
> networks where people are using server type hardware such as Windows(TM) 
> networks where DNS is used to locate and secure the network the renumbering 
> event creates major problems as the on premises DHCPv6 server has no way to 
> understand that a renumber event has occurred.  People are very used to the 
> IPv4 RFC 1918 static addressing where nothing on their local internal network 
> will change without notice.  The fact that ISPs can randomly change the 
> internal delegated address without notice is a major problem.  That will 
> confuse people and cause problems especially where a customer has equipment 
> such as Windows or Linux servers or other equipment that requires static 
> addressing or DHCPv6.   I understand that for certain operational reasons 
> ISPs need to renumber addresses however I suggest we discourage the practice. 
>  We also could modify the RFC to require a message to be sent by CPE to all 
> downstream
> network devices that a network renumber event is being scheduled.  This 
> can be sent as a multicast message that encodes the date that the renumbering 
> will occur.  I realize that we need to understand the security implications 
> of this.  This is just one idea that could smooth the renumbering events when 
> then have to happen for some operational reason. 
> 
> -Original Message-
> From: ipv6-ops-bounces+michael.sturtz=paccar@lists.cluenet.de 
>  
>  > On Behalf Of 
> ipv6-ops-requ...@lists.cluenet.de 
> Sent: Wednesday, October 23, 2019 3:00 AM
> To: ipv6-ops@lists.cluenet.de 
> Subject: ipv6-ops Digest, Vol 159, Issue 1
> 
> Send ipv6-ops mailing list submissions to
>     ipv6-ops@lists.cluenet.de 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>     
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.cluenet.de%2Fmailman%2Flistinfo%2Fipv6-opsdata=02%7C01%7Cmichael.sturtz%40paccar.com%7Ce0b1f347a5cf432a761e08d7579fc9b3%7Ce201abf9c5a343f88e29135d4fe67e6b%7C0%7C1%7C637074216137461832sdata=jmfELsU1SabFN%2BnPssOkByWoExIqjKfLhJCotAe40FA%3Dreserved=0
> or, via email, send a message with subject or body 'help' to
>     ipv6-ops-requ...@lists.cluenet.de 
> 
> 
> You can reach the person managing the list at
>     ipv6-ops-ow...@lists.cluenet.de 
> 
> 
> When replying, please edit your Subject line so it is more specific than 
> "Re: Contents of ipv6-ops digest..."
> 
> 
> 
> 
> 
> 

ULAs [was: ipv6-ops Digest, Vol 159, Issue 1]

[Brian E Carpenter]

Please don't send mail with useless "Digest" subject headers.

Michael, sorry to be blunt but you seem to have misunderstood ULAs.

My ULA prefix, for example, is fd63:45eb:dc14::/48 but my CE assigns addresses
in the subnet fd63:45eb:dc14::/64. If I ran a routed network at home, the 
routers
would each manage a different subnet in fd63:45eb:dc14::/48 and ULAs are
routeable within all those subnets, but are filtered at the CE/WAN interface.

It's correct that fc00::/8 is not used; all current ULA usage is in fd00::/8.
But so what? fc00::/8 is reserved for future use.

It is entirely possible for nodes within a SOHO network to be assigned ULAs only
(and therefore have no possibility of external access) or to be assigned both
ULAs and global addresses (for internal and external traffic respectively).
Sadly the makers of printers etc still have to catch up with that. But some
CEs, such as my rather ancient FritzBox, handle this very well.

You could look at
https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02
although that draft was never approved for RFC status.

Regards
   Brian Carpenter

On 24-Oct-19 04:51, Michael Sturtz wrote:
> The only current RFC on ULA is fc00::/7 but fc00::/8 remains undefined and 
> has not been accepted by IETF. The block fd00::/8 can be divided up.  All of 
> this said none of these addresses would be routable on the internet and since 
> a lot of the end user equipment can't handle a statically configured ULA 
> address and still obtain a routable address from SLAAC or DHCP6.  This 
> creates major problems for networks with limited IT support.  On larger 
> corporate networks with skilled IT people it's very likely that they will 
> have a static allocation from an ISP however smaller networks without IT 
> people it can become a serious problem.  Those people won't be skilled enough 
> to figure out ULAs anyway.  
> 
> -Original Message-
> From: Gert Doering  
> Sent: Wednesday, October 23, 2019 8:28 AM
> To: Michael Sturtz 
> Cc: Kristian McColm ; 
> ipv6-ops@lists.cluenet.de
> Subject: Re: ipv6-ops Digest, Vol 159, Issue 1
> 
> Hi,
> 
> On Wed, Oct 23, 2019 at 03:00:21PM +, Michael Sturtz wrote:
>> As far as I know ULA was deprecated in 9/2004 
> 
> Those were site-locals, not ULAs.
> 
> Gert Doering
> -- NetMaster
> 

Atlas probes and 6to4 [Re: IPv6 ingress filtering]

[Brian E Carpenter]

On 18-May-19 08:46, Nick Hilliard wrote:
> Brian E Carpenter wrote on 17/05/2019 21:06:
>> And surely the question is "What would produce the most help desk calls?".
>> Filtering something that is presumably working for its remaining users
>> might not be a good idea from that point of view.
> 
> 6to4 connectivity is probably already too broken to use.  Here are some 
> atlas measurements from a couple of days ago:
> 
> https://atlas.ripe.net/measurements/21449877/
> https://atlas.ripe.net/measurements/21449878/
> https://atlas.ripe.net/measurements/21449879/
> 
> This was 3-packet ping from the same 1000 probes to three ipv6 hosts. 
> The results were:
> 
> server in IE: 14.5% unreachability
> www.kame.net: 15.0% unreachability
> random 6to4 address: 23.1% unreachability
> 
> What's also unfortunate is after downloading the json results:
> 
>> % cat *.txt | jq '.[] | select (.rcvd == 0) | .from' | cut -d\" -f2 | grep 
>> ^2002 | sort | uniq -c
>>2 2002:2ea7:331c:0:1ad6:c7ff:fe2a:1a7c
>>1 2002:4e1a:aba9:10:fa1a:67ff:fe4d:7ee9
>>1 2002:4e79:421e:0:a62b:b0ff:fee0:ae0
>>1 2002:5253:a51b:0:1:e3ff:febb:121b
>>2 2002:55d4:648c:0:f6f2:6dff:fe5d:a19c
>>1 2002:566:3896:0::b3ff:feb0:e87a
>>3 2002:568:1047:1:220:4aff:fee0:20ac
>>2 2002:592:4daf:0:1:7dff:feac:317e
>>2 2002:5aba:3e12:1:eade:27ff:fe69:b644
>>1 2002:5b64:65f8:0:a62b:b0ff:fee0:1572
>>2 2002:5b73:5fdd::c66e:1fff:fe3a:d118
>>2 2002:8603:d75b:0:280:a3ff:fe91:408d
>>1 2002:b2f8:fe64:0:a2f3:c1ff:fec4:591c
>>2 2002:d58f:794c:0:eade:27ff:fe69:c8fa
>>2 2002:d5d1:57ac:1:c24a:ff:fecc:99fa
>> %

What does the leading digit (1, 2 or 3) mean? Because all
those with "1" are pingable from here, but none of the others.

> I.e. 1.5% of the sample probes were using 6to4.  Of these, 8 had 
> connectivity to the two control hosts, but not to the 6to4 host.  This 
> is awful!

If they are nodes using the deprecated anycast solution to get their
6to4 connectivity, this is unfortunately the expected result, and exactly
why we deprecated it. But in any case, Atlas probes with 6to4 addresses
seems pathological to me. However, there is a bit more to learn (see
below).

> Anyway, none of this exceeds the level of "anecdatum", but it's 
> potentially interesting nonetheless, and it does suggest connectivity 
> problems between the 6to4 network and chunks of the native ipv6 internet.

Yes, and if they are *not* using the anycast solution, it means that
the return path via a route to 2002::/16 is not working.

I tried to traceroute one of them (Probe #3009) at
2002:568:1047:1:220:4aff:fee0:20ac
and it petered out at 6to4.tyo1.he.net [2001:470:0:17a::2]

The embedded IPv4 address is 5.104.16.71, which is reachable,
and is indeed the published address of probe #3009, so it does
indeed look like a failure in the return relay path.

The same thing for a couple of other of the probes tagged "2"
or "3" in the above list, chosen at random.

But the ones tagged "1" seem to work. For example,
2002:566:3896:0::b3ff:feb0:e87a works. Its embeded IPv4
address is 5.71.38.96, which allegedly belongs to BSKYB in
the UK. (It's probably probe #13420 whose details are private.)

Dear he.net, RFC3056 says that a site MUST NOT advertise a route
to 2002::/16 unless it's willing to act as a relay router, which
means relaying to *any* IPv4 address. Could it be that 6to4.tyo1.he.net
is only willing to relay to a limited set of IPv4 addresses? If so, 
the external BGP4 route to 2002::/16 needs to die. If not, the problem
lies elswhere.

(Why do I bother, not being an operator? Maybe some slight guilt
at having propagated 6to4 in the first place...)

   Brian

Re: IPv6 ingress filtering

[Brian E Carpenter]

On 18-May-19 09:07, Kurt Buff - GSEC, GCIH wrote:
> On Fri, May 17, 2019 at 1:59 PM Enno Rey  wrote:
>>
>> Hi,
>>
>> On Fri, May 17, 2019 at 01:45:56PM -0700, Kurt Buff - GSEC, GCIH wrote:
>>> Forgive the intrusion, as I seek a bit of clarity.
>>>
>>> MSFT DirectAccess seems to use the address range in question:
>>>
>>> Tunnel adapter iphttpsinterface:
>>>
>>>Connection-specific DNS Suffix  . :
>>>IPv6 Address. . . . . . . . . . . : 
>>> 2002:4332::::::
>>>Temporary IPv6 Address. . . . . . : 
>>> 2002:4332::::::
>>>Temporary IPv6 Address. . . . . . : 
>>> 2002:4332::::::
>>>Link-local IPv6 Address . . . . . : fe80::75e4:c4b3:fae6:237c%2
>>>Default Gateway . . . . . . . . . :
>>>
>>> It seems to me that filtering this range might hurt a bit, unless I'm
>>> mistaking what some are proposing.
>>
>> not being an MS DirectAccess expert I'd say that - given DA is a VPN 
>> technology, using IP-HTTPS as a (somewhat proprietary) tunnel tech - these 
>> addresses shouldn't be visible too much "in the [public] IPv6 Internet" so 
>> the proposed filtering (of this thread) shouldn't come into play.
>>
>> cheers
>>
>> Enno
> 
> So, network filters aren't going to gratuitously inspect IPv4 packets
> for IPv6 content.

Let's hope not, but what possessed Microsoft to make them use the
2002::/16 prefix in this way is an interesting question in itself.
In 6to4 format, 4332: would imply a site IPv4 address of
67.50.170.170. And :::ffff doesn't look much like
a pseudo-random temporary interface identifier.

Maybe it's never a good idea to look underneath the hood of a VPN.

Brian
> 
> Seems reasonable to me.
> 
> Thanks,
> 
> Kurt
> 
>>>
>>> Kurt
>>>
>>> On Fri, May 17, 2019 at 1:06 PM Brian E Carpenter
>>>  wrote:
>>>>
>>>> On 18-May-19 06:12, Gert Doering wrote:
>>>>> Hi,
>>>>>
>>>>> On Fri, May 17, 2019 at 12:55:33PM -0500, David Farmer wrote:
>>>>>> A few questions;
>>>>>>
>>>>>> Are you generating ICMPv6 toward non-2002::/16 sources for traffic 
>>>>>> destined
>>>>>> to 2002::/16?
>>>>>> Are you generating ICMPv6 toward 2002::/16 source for traffic destined to
>>>>>> non-2002::/16?
>>>>>> For the later, where are you getting the route for 2002::/16 from?
>>>>>
>>>>> Indeed, as you said, filtering correctly (= ICMP unreachable, so clients
>>>>> can fail over quickly [if HE is not in use]) is hard.
>>>>>
>>>>> We still run our own relay, so do not filter today.  Mostly because I
>>>>> know it works and (since it's our relay) I can rely on it to not break
>>>>> things for people - and haven't had time to change that to "filter".
>>>>
>>>> And surely the question is "What would produce the most help desk calls?".
>>>> Filtering something that is presumably working for its remaining users
>>>> might not be a good idea from that point of view.
>>>>
>>>> Brian
>>
>> --
>> Enno Rey
>>
>> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>>
>> Handelsregister Mannheim: HRB 337135
>> Geschaeftsfuehrer: Florian Grunow, Enno Rey
>>
>> ===
>> Blog: www.insinuator.net || Conference: www.troopers.de
>> Twitter: @Enno_Insinuator
>> ===
> 

Re: IPv6 ingress filtering

[Brian E Carpenter]

On 18-May-19 06:12, Gert Doering wrote:
> Hi,
> 
> On Fri, May 17, 2019 at 12:55:33PM -0500, David Farmer wrote:
>> A few questions;
>>
>> Are you generating ICMPv6 toward non-2002::/16 sources for traffic destined
>> to 2002::/16?
>> Are you generating ICMPv6 toward 2002::/16 source for traffic destined to
>> non-2002::/16?
>> For the later, where are you getting the route for 2002::/16 from?
> 
> Indeed, as you said, filtering correctly (= ICMP unreachable, so clients
> can fail over quickly [if HE is not in use]) is hard.
> 
> We still run our own relay, so do not filter today.  Mostly because I 
> know it works and (since it's our relay) I can rely on it to not break
> things for people - and haven't had time to change that to "filter".

And surely the question is "What would produce the most help desk calls?".
Filtering something that is presumably working for its remaining users
might not be a good idea from that point of view.

Brian

Re: IPv6 ingress filtering

[Brian E Carpenter]

On 17-May-19 06:34, David Farmer wrote:
> 
> 
> On Thu, May 16, 2019 at 1:20 PM Sander Steffann  > wrote:
> 
> Hi David,
> 
> > While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and 
> RFC 7526 is quite clear that 2002::/16 is still valid. However, it is 
> perfectly permissible to filter it, if that is the policy a network operator 
> wishes to enforce.
> 
> With the 6to4 anycast relays deprecated the only 6to4 traffic should be 
> src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves can 
> filter 2002::/16. Everybody else will only see IPv4+proto41 traffic, which is 
> not impacted by that filter.
> 
> 
> NO! RFC3056 Includes a gateway functionality it is just not Anycast.  

Indeed. The Anycast hack was invented some time after 6to4 was standardised, 
and for a completely different purpose. Filtering the 6to4 IPv4 anycast address 
is a sensible thing to do for an IPv6-supporting ISP. Filtering 2002::/16 is 
unnecessary and breaks harmless traffic. (And there is so little such traffic 
that it is truly harmless.)

   Brian

> It is possible to locally gateway traffic to native IPv6 and then you would 
> get traffic sourced from 2002::/16 and then you need to send traffic to a 
> return gateway.  Now, most traffic you are seeing is probably coming from the 
> public anycast gateways that are still running, but it doesn't have to be. As 
> I said elsewhere in the thread, it complicated and filtering is easy. Read 
> RFC7526 very carefully, if you care, if you don't just filter it.
> 
> Thanks
> -- 
> ===
> David Farmer               Email:far...@umn.edu 
> 
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota  
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===

Re: IPv6 ingress filtering

[Brian E Carpenter]

On 15-May-19 04:22, Amos Rosenboim wrote:
> Let me just clarify few points:
> The suggested filter is not for the protocol, but for the 2002::/16 address 
> space.

Sure. But this is quite complicated; more complicated than I imagined when we 
invented 6to4. I really suggest reading https://tools.ietf.org/html/rfc6343 and 
then https://tools.ietf.org/html/rfc7526 carefully, for those that haven't done 
so.

According to Google statistics, 6to4 has been immeasurably small for at least a 
year (0.00%), but I don't see why it would do you any harm.
 
> Also the traffic I am seeing is between addresses  within this prefix to 
> addresses of our native IPv6 users.

That's exactly what you should see, IMHO. What % of total IPv6 traffic is that, 
as a matter of curiosity?
 
> As for policy - we tend to be as permissive as we can, and we certainly 
> wouldn’t like to restrict what is left from p2p apps.

No argument from me.

   Brian

> 
> Amos
> 
> Sent from my iPhone
> 
> On 14 May 2019, at 18:50, JORDI PALET MARTINEZ  > wrote:
> 
>> Hi Marc,
>>
>>  
>>
>> I don’t agree. There are many users with tunnel brokers that use 6in4. If 
>> you filter 6to4 as a protocol, you’re also filtering all those users’ 
>> traffic.
>>
>>  
>>
>> Not everybody is lucky enough to have native IPv6 support from its ISP.
>>
>>
>> Saludos,
>>
>> Jordi
>>
>>  
>>
>>  
>>
>>  
>>
>> El 14/5/19 17:46, "Marc Blanchet" 
>> >  en 
>> nombre de marc.blanc...@viagenie.ca > 
>> escribió:
>>
>>  
>>
>> 6to4 has been a good transition technology to help deploy IPv6 in the early 
>> days. However, it has intrinsically bad latency issues as its routing is 
>> based on the underlying IPv4, which can be pretty bad for non 6to4 
>> destinations (e.g. normal IPv6 addresses). Moreover, its IPv6 in IPv4 
>> tunnelling technology is likely to be filtered by various intermediate 
>> devices in the path. My take is that we shall declare 6to4 over and dead, 
>> thank you very much for your service. So I would suggest to filter it. If 
>> not, users may get latency issues that will go into support calls 
>> unncessarily.
>>
>> Marc.
>>
>> On 14 May 2019, at 11:24, Amos Rosenboim wrote:
>>
>> Hello,
>>
>>  
>>
>>  
>>
>> As we are trying to tighten the security for IPv6 traffic in our 
>> network, I was looking for a reference IPv6 ingress filter.
>>
>> I came up with Job Snijders suggestion (thank you Job) that can be 
>> conveniently found at whois -h whois.ripe.net  
>> fltr-martian-v6
>>
>>  
>>
>> After applying the filter I noticed some traffic from 6to4 addresses 
>> (2002::/16) to our native IPv6 prefixes (residential users in this case).
>>
>> The traffic is a mix of both UDP and TCP but all on high port numbers on 
>> both destination and source.
>>
>> It seems to me like some P2P traffic, but I really can’t tell.
>>
>>  
>>
>> This got me thinking, why should we filter these addresses at all ?
>>
>> I know 6to4 is mostly dead, but is it inherently bad ?
>>
>>  
>>
>> And if so, why is the prefix (2002::/16) still being routed ?
>>
>>  
>>
>> Thanks,
>>
>>  
>>
>> Amos Rosenboim
>>
>> -- 
>>
>>  
>>
>>
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>>
>> This electronic message contains information which may be privileged or 
>> confidential. The information is intended to be for the exclusive use of the 
>> individual(s) named above and further non-explicilty authorized disclosure, 
>> copying, distribution or use of the contents of this information, even if 
>> partially, including attached files, is strictly prohibited and will be 
>> considered a criminal offense. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the contents of 
>> this information, even if partially, including attached files, is strictly 
>> prohibited, will be considered a criminal offense, so you must reply to the 
>> original sender to inform about this communication and delete it.
>>

Re: Implementation/deployment wiki for IPv6?

[Brian E Carpenter]

Thanks to Jens Link, there is the very beginning of such
a wiki at https://wiki.ask-for-ipv6.net/

Please read, register and contribute!

Regards
   Brian Carpenter

On 21-Feb-19 15:47, Brian E Carpenter wrote:
> Hi,
> 
> Is anybody aware of a general implementation/deployment wiki for IPv6?
> 
> The reason is that I'm looking for somewhere to host a wiki about
> support for the IPv6 Flow Label, and hanging it off a general wiki
> seems like one option.
> 
> Regards
>Brian Carpenter
> 

Re: Link-local and ACLs

[Brian E Carpenter]

On 25/07/2017 19:07, Gert Doering wrote:
> Hi,
> 
> On Tue, Jul 25, 2017 at 10:41:06AM +1200, Brian E Carpenter wrote:
>> Why would you ever do it for normal traffic? 
> 
> I'm not sure that was a question asked in this thread :-)
> 
>> And why would ACLs be relevant for on-link traffic?
> 
> Interface ACLs are relevant for all packets leaving or entering an
> interface, generally...

Yes, but why are they relevant except for routers? I didn't see
anything in the original message that limited its scope to routers.
Most nodes aren't routers. I don't expect to see ACLs on normal
hosts.

> So, to stay with Tore's example, if you want to make NDP work on an IXP,
> you need to permit fe80->fe80, fe80->GUA, etc. in your ACLs - which ends
> up needing quite a number of lines to cover all cases

Fair enough. IXPs are a bit of a special case, though.

   Brian

> 
> #sh access-lists ipv6 internet-ipv6-in | inc icmp
>  20 permit icmpv6 fe80::/64 2001:7f8::/64 135 0
>  30 permit icmpv6 2001:7f8::/64 2001:7f8::/64 135 0 ttl eq 255
>  40 permit icmpv6 2001:7f8::/64 2001:7f8::/64 136 0 ttl eq 255
>  50 permit icmpv6 any ff02::/64 135 0
>  60 permit icmpv6 fe80::/64 fe80::/64 135 0
>  70 permit icmpv6 any fe80::/64 135 0
>  80 permit icmpv6 any fe80::/64 136 0
>  90 permit icmpv6 any host ff02::1 136 0
>  100 deny icmpv6 any any 135 log
>  110 deny icmpv6 any any 136 log
> 
> (Example for DECIX which uses 2001:7f8::/64 on-link)
> 
> Gert Doering
> -- NetMaster
> 

Re: Link-local and ACLs

[Brian E Carpenter]

On 25/07/2017 09:10, Tore Anderson wrote:
> * Brian E Carpenter
> 
>> So, I'm not aware of any realistic case where this happens, or any
>> reason for it.
> 
> As Gert already pointed out: Neighbour Discovery.

Well yes, like ARP. But that's the exception that proves the
rule - you do it when that is really what you mean *and*
the target address is within an on-link prefix.

I can do it too, even from Windows:

ping -n 100 -S fe80::c0de:dead:beef:768e%11 2001:df0:0:2006:c0de:beef:dead:be83

Those addresses are obfuscated, but you get the idea, and
I see the ICMPv6 packets with Wireshark, but get no replies.

Why would you ever do it for normal traffic? And why
would ACLs be relevant for on-link traffic?

   Brian

> 
> A few examples from an IX near me:
> 
> 23:06:11.020045  In IP6 fe80::8678:acff:fe66:80db > 2001:7f8:12:1::3:9029: 
> ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
> 23:06:11.563763  In IP6 fe80::aa0c:dff:fe71:5768 > 2001:7f8:12:1::3:9029: 
> ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
> 23:06:29.958824  In IP6 fe80::92e2:baff:fe3f:7665 > 2001:7f8:12:1::3:9029: 
> ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
> 23:06:34.239488  In IP6 fe80::523d:e5ff:fe89:4ec4 > 2001:7f8:12:1::3:9029: 
> ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
> 23:06:45.177659  In IP6 fe80::2c1:64ff:fe60:380 > 2001:7f8:12:1::3:9029: 
> ICMP6, neighbor solicitation, who has 2001:7f8:12:1::3:9029, length 32
> 
> Tore
> .
> 

Re: SixXS shutting down 2017-06-06

[Brian E Carpenter]

Below...

On 24/03/2017 06:39, Jeroen Massar wrote:
> On 2017-03-23 18:28, David Farmer wrote:
>>
>>
>> On Thu, Mar 23, 2017 at 10:46 AM, Brian E Carpenter
>> <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote
>>  
>>
>> One detail not mentioned in the /sunset page. Will you leave the
>> ULA tool and registry in place (https://www.sixxs.net/tools/grh/ula/
>> <https://www.sixxs.net/tools/grh/ula/>) ?
>> I believe some people like that.
>>
>>Brian
>>
>>
>> I'd be interested in some data on the use of the ULA tool and registry,
>> I'd especially be interested in use over time.  Is use of the ULA
>> registry increasing or decreasing over the last few years?
> 
> That is an easy question to answer:
> 
> $ SELECT YEAR(ula_date) AS Year, COUNT(*) AS Count FROM grh_ulas GROUP
> BY YEAR(ula_date);
> +--+---+
> | Year | Count |
> +--+---+
> | 2007 |63 |
> | 2008 |   140 |
> | 2009 |   321 |
> | 2010 |   611 |
> | 2011 |   835 |
> | 2012 |   742 |
> | 2013 |   724 |
> | 2014 |  1096 |
> | 2015 |  1303 |
> | 2016 |   640 |
> | 2017 |   143 |
> +--+---+
> 11 rows in set (0.00 sec)
> 
> I would say that it is going down if we look at that count ;)
> 
>> Basically,
>> is there an argument for further or new work within the IPv6 community
>> on this front?
> 
>>From my POV not really. It is extremely simple to get a prefix from one
> of the RIRs. Yes, it costs some money, which is something that should be
> addressed IMHO. (routing gear etc costs money too though).
> 
> Also, more importantly, ULA is random per definition, and the chance of
> collisions is extremely low. (unless one does not use randomness).

I agree. I have never thought that ULA registration was useful. But
apparently some people were worried enough about collisions to use
the registry. In any case the little tool to generate a ULA prefix
is of value, so I hope you can leave that available.

Brian

> 
>> Or, should this service just be sustained as-is, maybe
>> finding a new home or new support over the long-term?  Or, should this
>> service also be sunset, maybe not on the same timeframe as the other
>> SixXS services?
>>
>> Personally, if anything, I like to see some new work here, but I'd like
>> to drive what that is or should be with some data. 
> 
> Like with many things, I first would ask: what are the
> requirements/usecases/etc.
> 
>> Finally, many thanks to SixXS for their years of service to the IPv6
>> community!  And, kudos for planning an orderly sunset, rather than
>> decaying into oblivion.   
> 
> We have been warning people since December 2015. Hopefully since then
> they actually called their ISP or changed to ones that support IPv6.
> 
> Greets,
>  Jeroen
> 
> 
> 

Re: Fwd: SixXS shutting down 2017-06-06

[Brian E Carpenter]

As for the thanks, let me start here: *many* thanks.

> We note the trend of traffic is on a downwards trajectory since H2 2015.

I can see that, although I'd have been tempted to wait until it was closer
to zero (I think 6bone traffic was negligible when it went off, and 6to4
traffic was negligible when we deprecated it).

One detail not mentioned in the /sunset page. Will you leave the
ULA tool and registry in place (https://www.sixxs.net/tools/grh/ula/) ?
I believe some people like that.

   Brian
On 24/03/2017 04:25, Pim van Pelt wrote:
> On Thu, Mar 23, 2017 at 4:19 PM, Thomas Schäfer 
> wrote:
> 
>> https://www.root.cz/clanky/sixxs-vypne-ipv6-tunely-sluzby-ukonci-6-cervna/
>>
> 
> The article sums it up quite well, and the author understood I think the
> rationale quite well. I've asked them to change the link at the top of
> their article from a WIP document that I had sent to the SixXS admin
> community this week, and instead point folks at
> https://www.sixxs.net/sunset/ which contains the rationale (also in Josh'
> forward upthread).
> 
> Obviously many users will be asking questions, or simply saying thanks over
> the next few days. I intend to engage with the IPv6 community next week,
> although my thoughts are kind of wrapped up in the sunset rationale here.
> Do let me know if you have thoughts or further discussion points. Would be
> happy to collate them from *NOG, ipv6-* and publish those as well.
> 
> All the best,
> Pim
> 
> 

Re: default IID mechanism (was Re: macos Sierra with CGA address?)

[Brian E Carpenter]

On 16/12/2016 00:12, Holger Zuleger wrote:
> 
>>> My info is, to set
>>> sysctl -w net.inet6.send.opstate=0
>>> to go back to mac address based eui64, but didn't checked it.
>>
>> Please don't resort to eui64. That's a bad idea. See RFC7721 and RFC707
> Hmm, yes but from an operating view...
> 
> In case of re-numbering your network, RFC72177217 (and SEND as well) is
> a step backward. Both EUI48 and the Windows random stable IID mech have
> the benefit of prefix independent IIDs.
> 
> The change of name to IP mapping in the DNS is ways easier if the IID
> remain the same. I have a small programm to re-generate additional 
> records if I have to introduce a new provider prefix (and delete the old
> one as well).
>
> If the IID is prefix dependent (CGA, RFC7216), than the best (or the
> only scalable way) is that the host itself updates the DNS via dynamic
> updates.
> And integrating dynamic dns into standard operating systems is another
> thing I'm  waiting for a long time now.

Using Dynamic DNS Update for this has been recommended since RFC4192 in
2005. We renewed that in https://tools.ietf.org/html/rfc7010#section-6.1 .
If many operators yell for it, it might even happen.

Brian

> BR
>  Holger
> 

Re: Linux and ULA support and default route

[Brian E Carpenter]

On 15/10/2016 00:57, Holger Zuleger wrote:
>> If the delegated prefix changes, you'll be simply postponing the local
>> communication failure, not prevent it.
> Only if the new prefix is different to the old one.
> 
>> The last year has convinced me that the best user experience is
>> achieved by having an in-home stable ULA prefix to complement the
>> ISP-delegated global prefix[es] [if any], and that all the internal
>> hostnames should resolve to the IPv6 addresses assigned from the ULA
>> prefix.
> Yes, but this is probably a bit different to the AVM behavior. I have in
> mind that the default configuration on Fritzboxes is to announce the ULA
> *only* if the upstream is down. 

Correct, there is an option to change that however.

   Brian

> Then your local active sessions breaks
> twice.

Re: Linux and ULA support and default route

[Brian E Carpenter]

On 13/10/2016 21:14, Lorenzo Colitti wrote:
> Of note is the fact that the ULA prefix being announced is the ubiquitous
> fd00::/64.

0 is a perfectly random number, just like the ubiquitous PIN code 1234.

But yes, this a sloppy job by the FritzBox. Hopefully they've fixed this in
more recent models.

> Great idea, ULAs.

In the right circumstances, yes, actually. And actually my circumstances
yesterday were right for a ULA prefix: the ISP failed to give my CE a prefix.
Today, they gave me a prefix, and so Linux gives me a default route.

   Brian

> 
> On Wed, Oct 12, 2016 at 9:16 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
>> This creates a tricky problem for homenet, I think, but I agree that my CE
>> is doing what that requirement says. This also creates a truly annoying
>> coding problem for me, which I won't go into here (except to gripe that
>> Linux
>> makes it very annoying indeed to discover your own global unicast address).
>>
>> Thanks
>>Brian
>>
>> On 13/10/2016 16:55, Lorenzo Colitti wrote:
>>> The linux host is correctly not adding a default route because the RA
>>> specifies a router lifetime of 0, likely due to RFC 7084 requirement G-4.
>>>
>>> On Wed, Oct 12, 2016 at 8:25 PM, Brian E Carpenter <
>>> brian.e.carpen...@gmail.com> wrote:
>>>
>>>> I'll send you the RA packet off-list.
>>>>
>>>> Brian
>>>>
>>>> On 13/10/2016 14:10, Brian E Carpenter wrote:
>>>>> On 13/10/2016 13:47, Lorenzo Colitti wrote:
>>>>>> On Wed, Oct 12, 2016 at 5:39 PM, Brian E Carpenter <
>>>>>> brian.e.carpen...@gmail.com> wrote:
>>>>>>
>>>>>>> But what it says (before I install the correct default route) is
>>>>>>>
>>>>>>> fd00::/64 via fe80::be05:43ff:fe8e:ce39 dev wlp2s0  proto ra  metric
>>>> 600
>>>>>>> pref medium
>>>>>>> fe80::/64 dev wlp2s0  proto kernel  metric 256  pref medium
>>>>>>>
>>>>>>> No default, as you can see.
>>>>>>>
>>>>>>
>>>>>> Do you have a tcpdump of the RA?
>>>>>
>>>>> No. Any suggestions how I can catch one? Would a Wireshark capture be
>>>> useful?
>>>>>
>>>>> Brian
>>>>>
>>>>
>>>
>>
> 

Re: Linux and ULA support and default route

[Brian E Carpenter]

This creates a tricky problem for homenet, I think, but I agree that my CE
is doing what that requirement says. This also creates a truly annoying
coding problem for me, which I won't go into here (except to gripe that Linux
makes it very annoying indeed to discover your own global unicast address).

Thanks
   Brian

On 13/10/2016 16:55, Lorenzo Colitti wrote:
> The linux host is correctly not adding a default route because the RA
> specifies a router lifetime of 0, likely due to RFC 7084 requirement G-4.
> 
> On Wed, Oct 12, 2016 at 8:25 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
>> I'll send you the RA packet off-list.
>>
>>     Brian
>>
>> On 13/10/2016 14:10, Brian E Carpenter wrote:
>>> On 13/10/2016 13:47, Lorenzo Colitti wrote:
>>>> On Wed, Oct 12, 2016 at 5:39 PM, Brian E Carpenter <
>>>> brian.e.carpen...@gmail.com> wrote:
>>>>
>>>>> But what it says (before I install the correct default route) is
>>>>>
>>>>> fd00::/64 via fe80::be05:43ff:fe8e:ce39 dev wlp2s0  proto ra  metric
>> 600
>>>>> pref medium
>>>>> fe80::/64 dev wlp2s0  proto kernel  metric 256  pref medium
>>>>>
>>>>> No default, as you can see.
>>>>>
>>>>
>>>> Do you have a tcpdump of the RA?
>>>
>>> No. Any suggestions how I can catch one? Would a Wireshark capture be
>> useful?
>>>
>>> Brian
>>>
>>
> 

Re: Linux and ULA support and default route

[Brian E Carpenter]

I'll send you the RA packet off-list.

Brian

On 13/10/2016 14:10, Brian E Carpenter wrote:
> On 13/10/2016 13:47, Lorenzo Colitti wrote:
>> On Wed, Oct 12, 2016 at 5:39 PM, Brian E Carpenter <
>> brian.e.carpen...@gmail.com> wrote:
>>
>>> But what it says (before I install the correct default route) is
>>>
>>> fd00::/64 via fe80::be05:43ff:fe8e:ce39 dev wlp2s0  proto ra  metric 600
>>> pref medium
>>> fe80::/64 dev wlp2s0  proto kernel  metric 256  pref medium
>>>
>>> No default, as you can see.
>>>
>>
>> Do you have a tcpdump of the RA?
> 
> No. Any suggestions how I can catch one? Would a Wireshark capture be useful?
> 
> Brian
> 

Re: Linux and ULA support and default route

[Brian E Carpenter]

On 13/10/2016 13:47, Lorenzo Colitti wrote:
> On Wed, Oct 12, 2016 at 5:39 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
>> But what it says (before I install the correct default route) is
>>
>> fd00::/64 via fe80::be05:43ff:fe8e:ce39 dev wlp2s0  proto ra  metric 600
>> pref medium
>> fe80::/64 dev wlp2s0  proto kernel  metric 256  pref medium
>>
>> No default, as you can see.
>>
> 
> Do you have a tcpdump of the RA?

No. Any suggestions how I can catch one? Would a Wireshark capture be useful?

Brian

Re: Linux and ULA support and default route

[Brian E Carpenter]

On 13/10/2016 13:05, Lorenzo Colitti wrote:
> On Wed, Oct 12, 2016 at 3:51 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
>> ::/0   :: !n   -1  1   137
>> lo
>>
> 
> I think !n means network unreachable. 

Sure. But that's the Ethernet interface which isn't connected, so that's 
correct.
The problem is the complete absence of a default route for the working (WiFi)
interface.

>Please provide the output of "ip -6
> route".

It's very unenlightening. The full table from "route" is more use.
But what it says (before I install the correct default route) is

fd00::/64 via fe80::be05:43ff:fe8e:ce39 dev wlp2s0  proto ra  metric 600  pref 
medium
fe80::/64 dev wlp2s0  proto kernel  metric 256  pref medium

No default, as you can see.

   Brian

Re: Linux and ULA support and default route

[Brian E Carpenter]

Hi Jeroen,
On 13/10/2016 12:16, Jeroen Massar wrote:
> On 2016-10-13 00:51, Brian E Carpenter wrote:
> [..]
>> Kernel IPv6 routing table
>> DestinationNext Hop   Flag Met Ref Use If
>> fd00::/64  fe80::be05:43ff:fe8e:ce39  UG   600 112 
>> wlp2s0
>> fe80::/64  :: U256 0 0 
>> wlp2s0
>> ::/0   :: !n   -1  1   137 lo
>> ::1/128:: Un   0   3 7 lo
>> fd00::c5bb:40f2:f3d5:94e4/128  :: Un   0   319 lo
>> fe80::9051:543a:4c9e:e93e/128  :: Un   0   211 lo
>> ff00::/8   :: U256 2  1763 
>> wlp2s0
>> ::/0   :: !n   -1  1   137 lo
> 
> Do you receive those prefixes over RA or manual config?

RA of course

> Is forwarding enabled? 

No

> What does the ra_accept sysctl say?

accept_ra = 1

> 
> Also 'ip -6 ro get ' can be very useful to check where the
> routing table thinks packets are supposed to go.

Well, once I create the default route it tells me exactly what it should,
for any global-scope address. But after reboot it says "unreachable"
for any address outside the ULA /64 (i.e. even the rest of the ULA /48
is unreachable).

It's broken, is all.

   Brian


> 
> In general on a Linux install from the last decade or so, avoid
> 'netstat' and 'ifconfig' and use iproute: 'ip ro sho' or 'ip -6 ro sho',
> 'ip -6 addr show'
> 
> Greets,
>  Jeroen
> 
> 

Re: MTU/MSS testing IPv6

[Brian E Carpenter]

On 26/05/2016 00:33, Ignatios Souvatzis wrote:
> On Fri, Apr 29, 2016 at 08:30:50AM +0200, Mikael Abrahamsson wrote:
>>
>> Hi,
>>
>> I've run into a scenario where a website doesn't seem to be listening to
>> PTB. I can reach them just fine from an MTU1500 clean IPv6 connection, but
>> if I reach from a MTU1500<->MTU1480<->MTU1500 connection, it doesn't work. I
>> don't get the big packets after SYN handshake.
>>
>> I've been considering asking iis.se (the .SE ccTLD registry) who are already
>> running multiple testing tools for web sites and domain name owners) to
>> include these kinds of testing, and perhaps develop more of them.
> 
> Yes please.  Guess what I'm trying to debug right know, and having a 
> reliable testing point out there would be an immense help.

Make sure you cover MSS negotiation failure as well as PMTUD failure.
I've seen that cause things to stop after the SYN even if the MTU was
reduced correctly.

Brian

Re: v6 naming and shaming - *.europa.eu

[Brian E Carpenter]

On 19/05/2016 15:46, Pete Mundy wrote:
>> On 19/05/2016, at 2:10 pm, Mike Taylor  wrote:
>>
>> I had the opportunity to set up a (small) ISP from scratch, so I just
>> did it, and made everything native Ipv4 and IPv6 from day one.
>>
> 
> You get credit for your website having a quad A :)
> 
> But what about DNS?
> 
> workstation:~ $ dig ns totalteam.co.nz +short
> ns3.discountdomains.co.nz.
> ns2.discountdomains.co.nz.
> ns1.discountdomains.co.nz.
> 
> workstation:~ $ dig  ns1.discountdomains.co.nz +short
> 
> workstation:~ $ dig  ns2.discountdomains.co.nz +short
> 
> workstation:~ $ dig  ns3.discountdomains.co.nz +short
> 
> :(

Give him a break. Probably that's why they sell him a "discounted" DNS service 
;-).

(Cheap, fast, dual-stack, pick any two?)

   Brian

Re: push apps failing in Android until you disable IPv6

[Brian E Carpenter]

On 14/05/2016 04:02, Lorenzo Colitti wrote:
> On Fri, May 13, 2016 at 3:27 PM, Mikael Abrahamsson 
> wrote:
> 
>> My guess is that any device which sees this, will install default IPv6
>> route but will only have link local addresses on the interface, thus there
>> is no source address to use to send packets to the world outside the link.
>>
> 
> You're forgetting that the device might have an an IPv6 address on the
> cellular interface, and an OS that uses the weak host model like Linux is
> perfectly happy to use the cellular interface's IPv6 address to send
> packets on the wifi interface.

Ouch. Yes, that's what we are incidentally trying to fix with
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host
but it will be a while before that becomes widespread.

   Brian

Re: ip switching from ipv4 to ipv6

[Brian E Carpenter]

On 30/04/2016 01:16, Mikael Abrahamsson wrote:
> On Fri, 29 Apr 2016, re wrote:
> 
>> but is there any explanation to the repeated changing of the ip address from 
>> ipv4 to ipv6?
> 
> https://en.wikipedia.org/wiki/Happy_Eyeballs
> 
> If network conditions change then IPv4 or IPv6 might be preferred over time. 
> It'll usually give a little bit of head-start for
> IPv6 (depending on implementation), but if v6 is significantly worse parts of 
> the time, then you'll see the client bouncing
> between versions.
> 

And look for the relevant browser option to switch it off. For Firefox it
seems to need network.http.fast-fallback-to-IPv4;false

   Brian

Re: Slow WiFi with Android Marshmallow & IPv6?

[Brian E Carpenter]

Ted,
On 25/04/2016 07:55, Ted Mittelstaedt wrote:
> Why Android doesn't support DHCPv6 is detailed here:
> 
> https://code.google.com/p/android/issues/detail?id=32621#c53

Yes, we all know Lorenzo's opinion, and the follow-up comments there
give the opposing opinions.

> 
> They say to use SLAAC and RFC6106.  I happen agree with their reasoning.  It 
> is Microsoft who needs to change, not Google.  The
> IPv6 standard does not require DHCPv6

Neither does the IPv4 standard, if we're being pedantic.

> and it's a model that is an archaic carryover from IPv4.

It happens to be preferred by a lot of enterprise network operators, so
equipment vendors & o/s really need to support both.

(Also, looking at the history of DHCP and ND/RA, DHCP is not actually
archaic; it's only about 3 years older than IPv6, and was not generally
available until after ND/RA was designed. IPv4 was very annoying to deploy
and prone to fat-finger errors before DHCP was retro-fitted.)

> For those who must run DHCPv6 on Android:
> 
> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client
> 
> Now I will also point out something else that affects ISPs - like
> Comcast (are you listening?) - and probably affected "this Belgian ISP"
> that Erik is reporting.
> 
> The issue really isn't what protocol is supported.  The issue is
> PROPER support of what protocol is selected.

Absolutely correct, which is why I find the Android choice short-sighted.
Having to install this as an add-on seems very unlikely to produce "PROPER"
support. The first user comment for that add-on is "Doesn't work. There is not
enough space in /system...". Duh.

   Brian

Re: Fwd: Curious situation - not urgent, but I'd like to know more

[Brian E Carpenter]

Kurt,

http://tools.ietf.org/html/rfc6343 explains the various 6to4 breakage modes.

It only works outside all IPv4 NATs, so is guaranteed to fail with a CGN in 
place.

Regards
   Brian


On 06/03/2016 12:52, Kurt Buff wrote:
> Sorry - meant to reply to the list...
> 
> 
> In-line...
> 
> On Fri, Mar 4, 2016 at 11:01 PM, Tore Anderson  wrote:
>> Hi Kurt,
>>
>> First of all, +1 to Brian's suggestion to disable 6to4. I'd also disable
>> Teredo.
> 
> OK - I'll try that on my test laptop also, then on hers if that
> doesn't break anything.
> 
> It's beginning to sound as if DirectAccess protocols are narrowing
> down to only ip-https and nat64/dns64.
> 
>>> On my test machine (Also Win8.1), sitting outside of my corporate
>>> firewall on a public IP address, I see the following:
>>>
>>> Tunnel adapter 6TO4 Adapter:
>>>
>>>Connection-specific DNS Suffix  . :
>>>Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>>>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>>>DHCP Enabled. . . . . . . . . . . : No
>>>Autoconfiguration Enabled . . . . : Yes
>>>IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)
>>
>> Ok, so this tells us that this machine has the public IPv4 address
>> 67.50.118.50 (0x43.0x32.0x76.0x32). 6ot4 requires public IPv4 addresses
>> to work, so on this machine it has at least a *chance* of working.
>>
>> Note that Windows won't activate 6to4 if the local address is a
>> special-use one, such as RFC1918 ones typically seen behind NAT.
> 
> Ah yes - as stated, my test laptop is on a public IP address, outside
> my firewall.
> 
>>> On her machine, which is on a wireless connection at her home on ATT,
>>> I see this:
>>>
>>> Tunnel adapter 6TO4 Adapter:
>>>
>>>Connection-specific DNS Suffix  . : attlocal.net
>>>Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>>>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>>>DHCP Enabled. . . . . . . . . . . : No
>>>Autoconfiguration Enabled . . . . : Yes
>>>IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)
>>
>> This tells us that her IPv4 address is 1.0.0.105. That's a completely
>> normal and public IPv4 address, so Windows proceeds to activate 6to4.
>> But I am going to assume that your user does not live in an APNIC lab,
>> which is where this prefix is currently being used...
> 
> You are correct - not in an APNIC lab - her ISP is ATT, and she's at her home.
> 
>> If ATT will allow her 6to4 packets through to the Internet in the first
>> place (they shouldn't), any server replies will not come back to her
>> but instead head straight to Geoff or George's tcpdump session. (With
>> some luck they'll be the topic of an amusing blog post.)
>>
>> The exact same breakage is bound to happen with CGN deployments using
>> 100.64.0.0/10, by the way.
> 
> Can you expand a bit on the above? I'm quite ignorant of what you're
> speaking, and would love to know more.
> 
> Why shouldn't ATT allow her 6to4 packet back, and what is the tcpdump
> session to which you refer? And, I've only recently become aware that
> CGN has its own address range, but don't understand why breakage would
> occur for 6to4.
> 
> Perhaps I need to start re-reading Understanding IPv6.
> 
> Kurt
> 

Re: Curious situation - not urgent, but I'd like to know more

[Brian E Carpenter]

I would suggest:

netsh interface ipv6 6to4 set state state=disabled

You don't want to go near 6to4 these days (http://tools.ietf.org/html/rfc7526).
Use real IPv6 or no IPv6.

Regards
   Brian (co-author of 6to4, but that was 15 years ago)

On 05/03/2016 13:06, Kurt Buff wrote:
> Reviving an old thread, with a new twist.
> 
> I've currently got a similar problem with another user, but with two
> differences:
>  - The connection in this case is ATT, not Comcast
>  - The machine this time is running Win8.1 and not Win7
> 
> What I've zeroed in on is two stanzas from ipconfig /all:
> 
> On my test machine (Also Win8.1), sitting outside of my corporate
> firewall on a public IP address, I see the following:
> 
> Tunnel adapter 6TO4 Adapter:
> 
>Connection-specific DNS Suffix  . :
>Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>DHCP Enabled. . . . . . . . . . . : No
>Autoconfiguration Enabled . . . . : Yes
>IPv6 Address. . . . . . . . . . . : 2002:4332:7632::4332:7632(Preferred)
>Default Gateway . . . . . . . . . : 2002:4332:7626::4332:7626
>DHCPv6 IAID . . . . . . . . . . . : 268435456
>DHCPv6 Client DUID. . . . . . . . : 
> 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
>DNS Servers . . . . . . . . . . . : 8.8.8.8
>NetBIOS over Tcpip. . . . . . . . : Disabled
> 
> Tunnel adapter Teredo Tunneling Pseudo-Interface:
> 
>Connection-specific DNS Suffix  . :
>Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>DHCP Enabled. . . . . . . . . . . : No
>Autoconfiguration Enabled . . . . : Yes
>IPv6 Address. . . . . . . . . . . :
> 2001:0:4332:7626:2803:8c2:bccd:89cd(Preferred)
>Link-local IPv6 Address . . . . . : fe80::2803:8c2:bccd:89cd%9(Preferred)
>Default Gateway . . . . . . . . . :
>DHCPv6 IAID . . . . . . . . . . . : 285212672
>DHCPv6 Client DUID. . . . . . . . : 
> 00-01-00-01-1E-45-38-94-00-26-2D-FA-9F-EF
>NetBIOS over Tcpip. . . . . . . . : Disabled
> 
> On her machine, which is on a wireless connection at her home on ATT,
> I see this:
> 
> Tunnel adapter 6TO4 Adapter:
> 
>Connection-specific DNS Suffix  . : attlocal.net
>Description . . . . . . . . . . . : Microsoft 6to4 Adapter
>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>DHCP Enabled. . . . . . . . . . . : No
>Autoconfiguration Enabled . . . . : Yes
>IPv6 Address. . . . . . . . . . . : 2002:100:69::100:69(Preferred)
>Default Gateway . . . . . . . . . :
>DHCPv6 IAID . . . . . . . . . . . : 553648128
>DHCPv6 Client DUID. . . . . . . . : 
> 00-01-00-01-1D-CC-30-DE-34-E6-D7-13-7E-02
>DNS Servers . . . . . . . . . . . : 1.0.0.1
>NetBIOS over Tcpip. . . . . . . . : Disabled
> 
> Tunnel adapter Teredo Tunneling Pseudo-Interface:
> 
>Media State . . . . . . . . . . . : Media disconnected
>Connection-specific DNS Suffix  . :
>Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
>Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>DHCP Enabled. . . . . . . . . . . : No
>Autoconfiguration Enabled . . . . : Yes
> 
> 
> 
> She's able to get an IPv4 connection at her location using our SSL
> VPN, and she states that when at her local coffee shop her
> DirectAccess connection works, though I haven't been able to confirm
> that yet.
> 
> I'm going to see next week if I can take a peek at her router/firewall
> configuration and glean any clues from it, and also see if she's
> willing to make a trip to the coffee shop to do some work with me from
> there.
> 
> I'm not certain if prefix policies have anything to do with this
> problem, as I'm not seeing the relevant IPv6 addresses for
> DirectAccess anywhere in her ipoconfig output.
> 
> Any thoughts or comments would be appreciated.
> 
> Kurt
> 
> On Sat, Dec 19, 2015 at 1:37 PM, Kurt Buff  wrote:
>> All,
>>
>> I ran into an interesting situation some months ago which still
>> baffles me, and though I was able to work around it, I expect it will
>> happen again.
>>
>> We implemented MSFT DirectAcess at our company quite some time ago
>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>
>> At least it worked well for everyone until one of the employees got
>> his Comcast connection upgraded, and then DirectAccess didn't work for
>> that employee any more.
>>
>> We proved that if he tethered to his cell phone, that would work, and
>> if he used an SSL VPN client while on his Comcast connect that would
>> work, but DirectAccess would not work at home.
>>
>> Finally, I discovered that his Comcast-installed router was handing
>> our IPv6 addresses on his home LAN. Turning that off enabled
>> DirectAccess to work again.
>>
>> We do not have an assigned IPv6 block from our ISP, though of course
>> MSFT OSes use it, and auto-assign themselves 

Re: Curious situation - not urgent, but I'd like to know more

[Brian E Carpenter]

On 21/12/2015 03:28, Marc Luethi wrote:
> Hi all
> 
> I suggest to investigate source address selection on the client side,
> while closely following name resolution (assuming this is similar to
> Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
> and keeping an eye on the IPv6 routing table.
> 
> In your situation, I would presume that the end system ends up with an RFC
> 4193 address (from the /48 that was initially chosen when DA was set up) on
> its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)
> and a global unicast address  the (W)LAN interface, based on the CPE's RAs.
> 
> While things *should* be neat, my experience with Windows 7's way of
> picking source addresses was so bad ("longest match" seemed entirely
> unheard-of), I eventually gave up using RFC 4193 addresses for my internal
> network altogether.
> 
> I repeateadely observed Win7 using its global unicast address(es) to access
> internal ressources, while stubbornly sticking to te RFC4193 source address
> when attempting to talk to addresses on the global IPv6 internet.

Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
RFC3484). It would be possible to make Win8 misbehave by changing the default
preferences (https://tools.ietf.org/html/rfc6724#section-10.6).

Conversely, it's possible to make Win7 behave correctly by changing its default
policies to conform to RFC6724. I just found the following site that offers a
script (YMMV, I haven't checked it):
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies

But if that is the cause of the original issue, maybe switching off the
ULA prefix would be easier, and nicer than switching off IPv6.

Brian Carpenter


> 
> cheers
> Marc
> 
> 
> 
> 
> On 19 December 2015 at 22:37, Kurt Buff  wrote:
> 
>> All,
>>
>> I ran into an interesting situation some months ago which still
>> baffles me, and though I was able to work around it, I expect it will
>> happen again.
>>
>> We implemented MSFT DirectAcess at our company quite some time ago
>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>
>> At least it worked well for everyone until one of the employees got
>> his Comcast connection upgraded, and then DirectAccess didn't work for
>> that employee any more.
>>
>> We proved that if he tethered to his cell phone, that would work, and
>> if he used an SSL VPN client while on his Comcast connect that would
>> work, but DirectAccess would not work at home.
>>
>> Finally, I discovered that his Comcast-installed router was handing
>> our IPv6 addresses on his home LAN. Turning that off enabled
>> DirectAccess to work again.
>>
>> We do not have an assigned IPv6 block from our ISP, though of course
>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>> we're ignoring it.
>>
>> Has anyone run into this problem and solved it - not by turning off
>> iIPv6 address assignment for the home LAN, but really solved it? If
>> so, how did you do that?
>>
>> Would getting and implementing an IPv6 assignment from our ISP cure
>> the problem, or make it worse?
>>
>> I've found little guidance from MSFT about DirectAccess in an IPv6
>> environment, though I admit I haven't been terribly diligent in my
>> searches.
>>
>> Kurt
>>
> 
> 
> 

Re: Curious situation - not urgent, but I'd like to know more

[Brian E Carpenter]

Just an update: I eyeballed the "PrefixPolicies-Vista78.cmd" script from
https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies, concluded
that it was safe, and ran it. It apparently works, but I don't have a
ULA setup to test it with.

jrey42 deserves kudos.

Regards
   Brian

On 21/12/2015 07:57, Brian E Carpenter wrote:
> On 21/12/2015 03:28, Marc Luethi wrote:
>> Hi all
>>
>> I suggest to investigate source address selection on the client side,
>> while closely following name resolution (assuming this is similar to
>> Windows 2012R2's DA implementation, DNS64 is supposed to be at work, here)
>> and keeping an eye on the IPv6 routing table.
>>
>> In your situation, I would presume that the end system ends up with an RFC
>> 4193 address (from the /48 that was initially chosen when DA was set up) on
>> its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)
>> and a global unicast address  the (W)LAN interface, based on the CPE's RAs.
>>
>> While things *should* be neat, my experience with Windows 7's way of
>> picking source addresses was so bad ("longest match" seemed entirely
>> unheard-of), I eventually gave up using RFC 4193 addresses for my internal
>> network altogether.
>>
>> I repeateadely observed Win7 using its global unicast address(es) to access
>> internal ressources, while stubbornly sticking to te RFC4193 source address
>> when attempting to talk to addresses on the global IPv6 internet.
> 
> Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not
> RFC3484). It would be possible to make Win8 misbehave by changing the default
> preferences (https://tools.ietf.org/html/rfc6724#section-10.6).
> 
> Conversely, it's possible to make Win7 behave correctly by changing its 
> default
> policies to conform to RFC6724. I just found the following site that offers a
> script (YMMV, I haven't checked it):
> https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies
> 
> But if that is the cause of the original issue, maybe switching off the
> ULA prefix would be easier, and nicer than switching off IPv6.
> 
> Brian Carpenter
> 
> 
>>
>> cheers
>> Marc
>>
>>
>>
>>
>> On 19 December 2015 at 22:37, Kurt Buff <kurt.b...@gmail.com> wrote:
>>
>>> All,
>>>
>>> I ran into an interesting situation some months ago which still
>>> baffles me, and though I was able to work around it, I expect it will
>>> happen again.
>>>
>>> We implemented MSFT DirectAcess at our company quite some time ago
>>> (using 2008R2 and Forefront 2010), and it works extremely well.
>>>
>>> At least it worked well for everyone until one of the employees got
>>> his Comcast connection upgraded, and then DirectAccess didn't work for
>>> that employee any more.
>>>
>>> We proved that if he tethered to his cell phone, that would work, and
>>> if he used an SSL VPN client while on his Comcast connect that would
>>> work, but DirectAccess would not work at home.
>>>
>>> Finally, I discovered that his Comcast-installed router was handing
>>> our IPv6 addresses on his home LAN. Turning that off enabled
>>> DirectAccess to work again.
>>>
>>> We do not have an assigned IPv6 block from our ISP, though of course
>>> MSFT OSes use it, and auto-assign themselves addresses, but for now
>>> we're ignoring it.
>>>
>>> Has anyone run into this problem and solved it - not by turning off
>>> iIPv6 address assignment for the home LAN, but really solved it? If
>>> so, how did you do that?
>>>
>>> Would getting and implementing an IPv6 assignment from our ISP cure
>>> the problem, or make it worse?
>>>
>>> I've found little guidance from MSFT about DirectAccess in an IPv6
>>> environment, though I admit I haven't been terribly diligent in my
>>> searches.
>>>
>>> Kurt
>>>
>>
>>
>>

Re: [v6ops] Why operators filter IPv6 packets with extension headers?

[Brian E Carpenter]

On 01/09/2015 22:06, Fernando Gont wrote:
> Hi, Eric,
> 
> Thanks so much for the timely feedback! Please find some comments inline
> (more in a subsequent email)...
> 
> 
> On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote:

...
>> - the processing of HbH would kill the Internet of course (at least with
>> most routers), should HbH be separately called?
> 
> I think that'd be sensible. -- and seem to recall that there was some
> I-D (RFC?) focusing on HbH? (or was it on router alert option?)

You're probably thinking of draft-baker-6man-hbh-header-handling,
but there's a slight conflict between that and RFC 7045, which
made a normative change to HbH by downgrading them to SHOULD:

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

Also of course the next version of 2460bis will revisit this topic.

  Brian

Re: Google no longer returning AAAA records?

[Brian E Carpenter]

On 17/04/2015 15:17, Erik Kline wrote:
 On Thu, Apr 16, 2015 at 7:41 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
 On 16/04/15 01:57, Lorenzo Colitti wrote:

 For the avoidance of mystery: Google performs measurements of IPv6
 connectivity and latency on an ongoing basis. The Google DNS servers do
 not return  records to DNS resolvers if our measurements indicate
 that for users of those resolvers, HTTP/HTTPS access to dual-stack
 Google services is substantially worse than to equivalent IPv4-only
 services. Worse covers both reliability (e.g., failure to load a URL)
 and latency (e.g., IPv6 is 100ms worse than IPv4 because it goes over an
 ocean). The resolvers must also have a minimum query volume, which is
 fairly low.


 Lorenzo,

 Thanks for the response.

 Do you know if Google have given any thought as to how long they might find
 it necessary to take these measures? Years, indefinitely?

 Just curious.
 
 It seems to keep on finding things, so...

But the incentive is wrong. Forcing users to drop back to IPv4 offers
no incentive to fix the IPv6 problem. The correct incentive would be to
tell an operator that they will be blacklisted unless they fix {X and Y}.

Brian

Re: Google no longer returning AAAA records?

[Brian E Carpenter]

I suggest checking if any of your affected users have broken 6to4 setups,
and that you are applying the relevant mitigations in RFC 6343.

MTU size issues and high latency have also both been mentioned as
possible reasons for the mysterious  blacklist.

It has also been said that n...@google.com never replies.

Regards
   Brian Carpenter

On 16/04/2015 07:16, Brian Rak wrote:
 On 4/15/2015 11:28 AM, Phil Mayers wrote:
 On 15/04/15 16:05, Brian Rak wrote:
 We noticed that we're no longer getting  results back for google.com
 when we do queries from a few of our recursive servers (other ones are
 fine).

 A bit of searching revealed that a few of our servers are listed here
 http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_.txt
 (there are 4 listed for AS20473, which are the ones I'm referring to)

 However, I can't seem to find any information about why we'd be listed
 there, nor can I find anything telling me how to get delisted.

 Yes. They don't provide that info, nor do they provide a way to request a 
 de-listing AFAIK.

 You'll be removed automatically when the problem goes away.

 There's a lot of discussion in the archives about this, but I believe that, 
 as far as is known publicly:

  1. There's a web-bug in the google search page
  2. They correlate IPv6 failures of this against the DNS lookup
  3. When the DNS source IP hits a certain threshold of correlatd failures, 
 they stop serving  records for a time (one week?).

 Subjectively it's irritating that Google don't provide info to operators as 
 to the specifics of the cause, but look at it from
 their PoV - there's a lot of info, some of it potentially personal / 
 data-protected, that they'd have to communicate securely
 to operators when they ask.

 It would be a lot of work for them and I'm somewhat sympathetic on that 
 basis (although I wasn't when it was happening to us ;o)

 My guess: you've got some form of broken IPv6 connectivity talking to your 
 resolvers; maybe rogue RAs, a tunnel, VPN, etc.

 The customers with this problem aren't reporting it because Happy Eyeballs, 
 but the Google web-bug is detecting it.

 We saw a reduction (and eventual end to) our experiences of this when we 
 finished our native dual-stack deployment *and* when
 we blacklisted serving of  to some of our more troublesome netblocks - 
 mainly remote access VPN users.

 We monitor whether google are blacklisting us in our Nagios setup, so we can 
 see if problems come back.

 An alternative might be to steer different classes of users to different 
 resolver query source IPs (either actual different
 resolvers, or using views  multiple IPs). Then, you can see which source IP 
 and thus class of users is triggering it.

 Good luck tracking it; it can be frustrating :o(

 Cheers,
 Phil
 
 Well, we're a hosting provider and we have a very large number of users doing 
 all sorts of crazy things.  These particular
 resolvers are used by our low cost virtual server platform, so we see many 
 users running a wide variety of proxy software.  It's
 pretty difficult to prevent people from breaking their IPv6 connectivity when 
 they have full control over the machines.
 
 There may be some things that we can do to reduce the number of broken IPv6 
 setups.. I just wasn't sure if we'd ever drop off
 that list automatically.
 
 

Re: Cost of IPv6 for IT operations team

[Brian E Carpenter]

 The 20% figure is based on an IETF document

Which one? We can fix that if people think it's wrong.
(This comes just too late for yesterday's v6ops meeting
at the IETF in Dallas.)

Regards
   Brian

Re: Cost of IPv6 for IT operations team

[Brian E Carpenter]

Christophe,

On 28/03/2015 01:56, BERENGUER Christophe wrote:
 Hi,
 
 I have found the figure in this document : 
 https://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-05#section-3.4

That is a very old and expired personal draft, not an IETF document. Very 
dangerous
to rely on such a document. It was eventually replaced by a working group draft
http://tools.ietf.org/html/draft-ietf-v6ops-dc-ipv6-01#section-2.5.4
but that has not been accepted to become an RFC and has also expired
after an unsuccessful WG Last Call.

(You can always check the status of an Internet-Draft at
https://datatracker.ietf.org/doc/ .)

But in any case, look at the full context:
   Depending of the complexity of the DC network, provisioning and other
   factors we estimate that the extra costs (and later savings) may be
   around between 15 to 20%.

Note the parenthesis!

Regards
Brian

 Regards,
 
 Christophe BERENGUER
 Consultant
 Fixe : +33 (0)1 49 03 85 86
 christophe.bereng...@solucom.fr
 solucom
 Tour Franklin : 100 - 101 terrasse Boieldieu
 92042 Paris La Défense Cedex
 
 
 De : Brian E Carpenter brian.e.carpen...@gmail.com
 Envoyé : vendredi 27 mars 2015 13:21
 À : BERENGUER Christophe
 Cc : Ted Mittelstaedt; ipv6-ops@lists.cluenet.de
 Objet : Re: Cost of IPv6 for IT operations team
 
 The 20% figure is based on an IETF document
 
 Which one? We can fix that if people think it's wrong.
 (This comes just too late for yesterday's v6ops meeting
 at the IETF in Dallas.)
 
 Regards
Brian
 
 

Re: Cost of IPv6 for IT operations team

[Brian E Carpenter]

On 26/03/2015 22:04, BERENGUER Christophe wrote:
 Hello everybody,
 
 
 I work for a consulting firm.
 
 
 For a client, I would like to estimate the work overload for IT operations 
 team to deploy IPv6 dual stack and for day to day operations.
 
 
 On the internet, I have found an estimation around 20% of work overload for 
 the run phase.

Is that evidence-based, or a hand-waving guess?
I would expect a bit of extra workload at the beginning of the run phase
but in the steady state are there really 20% more incidents?

Brian

 But if you have operational feedback it would be the best!
 
 
 Thanks in advance for your answers,
 
 Have a nice day.
 
 
 Best regards,
 
 
 Christophe BERENGUER
 Consultant
 Fixe : +33 (0)1 49 03 85 86
 christophe.bereng...@solucom.frmailto:christophe.bereng...@solucom.fr
 solucom
 Tour Franklin : 100 - 101 terrasse Boieldieu
 92042 Paris La Défense Cedex
 

Re: IPv6-only residential service (MAP, lw4o6)

[Brian E Carpenter]

On 07/12/2014 09:08, Ca By wrote:
 On Saturday, December 6, 2014, Yannis Nikolopoulos d...@otenet.gr wrote:
 
  Hello,

 IPv4-only CGN was never on the table to begin with. DS-lite doesn't seem
 to scale so well, that's why we were focusing on the more stateless
 approaches. We have

 
 
 I hear this argument frequently (stateful bad, stateless good) but it is
 seldom coupled with deployment experience.

unmanaged stateless bad (see experience with anycast-6to4 and Teredo).

Indeed I think we lack feedback on experience with ISP-managed stateless,
except for rude words about RFC 6732 6to4 Provider Managed Tunnels.

   Brian

 
 Makes you wonder why some of the largest ipv6-only deployments are stateful
 (ds-lite, 464xlat, ...) and the stateless solutions are not even published
 as rfcs or deployed at scale yet?
 
 
 
 been running a native (dual-stack) IPv6 network for years, so you're
 right, IPv4-only CGN would be a move backwards.
 I also agree about testing, PoCs and friendly trials but we don't have the
 luxury to test a few solutions before deciding, as time is of essence

 cheers,
 Yannis

 p.s: 464xlat was never considered because I always thought of it as a
 mobile solution.

 On 12/06/2014 06:24 PM, Ca By wrote:

 Hi,


 On Friday, December 5, 2014, Yannis Nikolopoulos d...@otenet.gr
 javascript:_e(%7B%7D,'cvml','d...@otenet.gr'); wrote:

  On 12/05/2014 05:48 PM, Lorenzo Colitti wrote:

  On Fri, Dec 5, 2014 at 10:30 PM, Yannis Nikolopoulos d...@otenet.gr
 wrote:

 I'm wondering, have people deployed IPv6-only residential services? I
 know of a couple of DS-lite implementations, but we'd be more interested to
 hear about network operators deploying either MAP or lightweight 4over6
 (not just trials though, but actual commercial services)

  Softbank (Japan) launched an IPv4-over-IPv6 service in August 2012.
 They use what looks to me to be an IPv4-in-IPv6 tunnel, but could be just a
 particular case of MAP-E with no portset. The service is up to 1G down / 1G
 up and they do encapsulation in hardware in a proprietary CPE.


 I remember them deploying 6rd, but I could be wrong.

 We're considering MAP or lw4o6. The

  Those and ds-lite are good. Ds-lite is clearly more deployed and mature
 on many fronts.



 problem is that our management prefers proven solutions (i.e deployed
 by other ISPs) and the only proven solutions I'm aware of are full blown
 CGN solutions.

  Please take cgn off the table if possible.

  At this point i will suggest that you also consider rfc6877. It is
 better than ipv4 only cgn since major traffic source (netflix, fb, google,
 youtube) are already ipv6 end to end.

  t-mobile us has deployed rfc6877 to over 25 million subscribers.  It is
 baked and works well for mobile, but you asked for residential. Rfc6877
 also covers the fixed line case too.

  Anyhow, the solution that is best for your network is the one that
 proves itself best in your own testing and proof of concept. This will show
 deal-breakers and vapor ware

  Proof of concepts and friendly trials with real customers are much more
 insightful than anything you will learn on this list.

  I would avoid 6rd unless you have and L1 or L2 limitation that prevents
 native ipv6.

  I would avoid ipv4 only cgn entirely since the roi will be so poor, it
 is a move backwards and you will have to do the real ipv6 project again in
 a few years.

  That's why I was trying to find commercially deployed cases based on
 either MAP or lw4o6. Alternatively, It would also be of value if I could
 prove that, for example, DS-lite is not being deployed either :)

 cheers,
 Yannis


 

Re: Routingproblems - Deutsche Telekom?

[Brian E Carpenter]

It works nicely from NZ (the ping time is typical), but
I'm seeing a different address:

C:\windows\system32ping www.linkedin.com

Pinging pop-ela4-alpha.www.linkedin.com [2620:109:c00d:100::c765:a381] with 32 
bytes of data:
Reply from 2620:109:c00d:100::c765:a381: time=201ms
Reply from 2620:109:c00d:100::c765:a381: time=210ms
Reply from 2620:109:c00d:100::c765:a381: time=200ms
Reply from 2620:109:c00d:100::c765:a381: time=200ms

Ping statistics for 2620:109:c00d:100::c765:a381:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 200ms, Maximum = 210ms, Average = 202ms

Regards
   Brian




On 22/11/2014 10:49, staticsafe wrote:
 On 11/21/2014 15:09, Thomas Schäfer wrote:
 Has anybody an idea? Can somebody confirm this problem by using a different 
 isp?

 Regards,
 Thomas
 
 I can replicate the issue on one of my servers.
 
 Box is in AS12876.
 
 Relevant mtr:
 
 inari.zombocloud.com | success | rc=0 
 HOST: inari Loss%   Snt   Last   Avg  Best  Wrst StDev
   1.|-- 2001:bc8:2::1:212:1   20.0%105.5   5.0   0.6  17.3   5.4
   2.|-- 2001:bc8:0:1::49   0.0%101.0   1.1   0.9   2.0   0.3
   3.|-- prs-b7-link.telia.net  0.0%101.0   0.9   0.9   1.0   0.0
   4.|-- ???   100.0100.0   0.0   0.0   0.0   0.0

Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt)

[Brian E Carpenter]

With the same Bcc:

Internet service
providers SHOULD filter out routes to 192.88.99.1. 

It is pretty clear enough to me (as document editor) that there
is no consensus in the v6ops WG for this sentence, which was
added after some earlier discussion in the WG. The final
consensus has to be judged by the WG chairs, but my guess is
that we'll delete that sentence and leave the decision up to
individual operators.

(The argument is that this route helps people who are still
successfully using anycast 6to4, whether intentionally or by
default, and filtering it would hurt them without helping anyone
else.)

Regards
   Brian

On 19/11/2014 20:56, Jeroen Massar wrote:
 BCC'ing ipv6-...@cluenet.net thus a bit of background info:
 
 draft-ietf-v6ops-6to4-to-historic-08.txt currently contains:
 
 Section 4 Deprecation
 8
Current operators of an anycast 6to4 relay with the IPv4 address
192.88.99.1 SHOULD review the information in [RFC6343] and the
present document, and then consider carefully when the anycast relay
can be discontinued as traffic diminishes.  Internet service
providers SHOULD filter out routes to 192.88.99.1.  However, networks
 
SHOULD NOT filter out packets whose source address is 192.88.99.1,
because this is normal 6to4 traffic from a 6to4 return relay
somewhere in the Internet.
 8
 
 Hence this BCC to poll what the operators of these current relays think
 about this and what they think they will do.
 
 Note that the discussion is really taking place on v6...@ietf.org hence
 to post you either have to be (temporarily) subscribed and/or post
 anyway and wait for one of the listadmins to approve your messages.
 
 Below the view that RIPEs RIS thinks are the current 6to4 anycast relays.
 
 On 2014-11-19 08:35, Tim Chown wrote:
 [..]
 I wonder what the first publicly announced IPv4 6to4 relay was.
 Perhaps SWITCH (via Simon Leinen) or FUNET (Pekka Savola)?
 I remember the days of SWITCH’s relay being a world 6to4 magnet.

 Would be poetic to let them be the last to switch off too, if they’re still 
 running :)
 
 Afaik the SWITCH one is gone for a long long time already.
 FUNET is still up, but only limited in BGP, only RRC13 in Moscow sees
 it, which is funny as for instance RRC07 in Stockholm does not.
 
 The list:
 https://stat.ripe.net/widget/looking-glass#w.resource=192.88.99.1
 
  8903 = ES BT Espana
  6939 = US Hurricane Electric*
  7575 = AU AARnet
 16150 = SE Availo (Port80)*
 12779 = IT ItGate*
  1103 = NL Surfnet*
  8954 = NL Intouch*
 15598 = DE QSC AG
 28917 = RU FIORD AS
 21416 = RU TCINET
  1741 = FI FUNET*
  8359 = RU MTS
 44581 = SE AllTele
 
 
 Note that only 6939/7575/8903 are 'globally' visible, others seem to
 have very limited announcement.
 
 * = person who operates it is well known, all of which will be on
 ipv6-ops@ hence, BCCd them that way to get them into the loop on this
 discussion as they will be the folks disabling those boxes or not.
 
 Greets,
  Jeroen
 
 ___
 v6ops mailing list
 v6...@ietf.org
 https://www.ietf.org/mailman/listinfo/v6ops
 

Re: Teredo sunset - did it happen?

[Brian E Carpenter]

I said:

 But if the client has the old RFC 3483 policy table,
 :::0:0/96 has the lowest precedence so Teredo would win over
 IPv4, which is a Bad Thing. There isn't much to be done about
 that unless the user has netsh skills.

s/3483/3484/

  Brian

On 18/11/2014 13:01, Brian E Carpenter wrote:
 On 18/11/2014 07:12, Phil Mayers wrote:
 On 17/11/2014 17:43, Darren Pilgrim wrote:

 Any ideas what's going on? Microsoft, anyone care to comment?
 Microsoft released an Windows Update for the prefix policy table.  The
 update dropped Teredo's precedence to lower than IPv4.
 Just to be clear - are you suggesting they did this instead of
 sunsetting Teredo altogether?

 In any case, I was always under the impression this was the day-one
 experience - Teredo would only be used to talk to another Teredo DNS
 name or an IPv6-only name in the absence of native IPv6. Am I mistaken?
 
 I think that was always the intention, but unmanaged tunnels are
 liable to behave undesirably. From what Dave Thaler said during
 the discussion at the IETF last week on deprecating 6to4, MS
 clearly sees Teredo for Xbox-to-Xbox as operational and Teredo
 for regular client/server use as undesirable, same as you do.
 Dave therefore wanted no change to the RFC 6724 default policy
 table, which I assume is exactly what Windows now ships.
 
 Then, even if the Teredo interface comes up, since
 :::0:0/96 has higher precedence than 2001::/32, Teredo will
 not be tried unless there is no IPv4 address at all for the
 target host.
 
 But if the client has the old RFC 3483 policy table,
 :::0:0/96 has the lowest precedence so Teredo would win over
 IPv4, which is a Bad Thing. There isn't much to be done about
 that unless the user has netsh skills.
 
 Brian
 

Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Brian E Carpenter]

On 03/11/2014 22:38, Bjørn Mork wrote:
...
 It just seems so pointless.  The dummy names will be longer than the
 address and will contain the exact same information.

Quite. It's idiotic. And if I was a paranoid mail operator, I would
put in some heuristic code to identify such dummy names and treat
them as if there was no PTR record, since they do nothing to actually
validate the source in any real way.

   Brian

Re: 6to4 in Internet aaaa records

[Brian E Carpenter]

On 03/10/2014 15:58, Ca By wrote:
 On Thu, Oct 2, 2014 at 7:47 PM, Jeroen Massar jer...@massar.ch wrote:
 
 On 2014-10-02 22:37, Ca By wrote:
 [..]
 Yes, i think .gov requires  records.  So it looks like DNS admins
 are generating  records that ultimately break connectivity.

 Back to my question, should there be an RFC generated that advises
 network admins to only put native natural addresses in DNS for anything
 that is supposed to be production grade and routed across the Internet?

 Meaning:

 1.  Only make  records from 2000::/3
 2002::/16 (6to4) is part of that.

 2.  Do not make  records with 6to4 addresses
 See http://tools.ietf.org/html/rfc6343

To save looking-up effort, here's what it says:

4.2.4. DNS Issues


   A customer who is intentionally using 6to4 may also need to create
    records, and the operator should be able to support this, even
   if the DNS service itself runs exclusively over IPv4.  However,
   customers should be advised to consider carefully whether their 6to4
   service is sufficiently reliable for this.

   Operators could, in principle, offer reverse DNS support for 6to4
   users [RFC5158], although this is not straightforward for domestic
   customers.

The point is that if you are crazy enough to rely on 6to4 to offer
IPv6 service, as it seems the people at www.azdes.gov are, you must
of course have a stable 6to4 server and provide a DNS entry,
and a reverse entry (RFC 5158) too. But as the rest of RFC 6343
should tell you, you really would have to be crazy.

I have to say that this deployment seems to be broken in a way
that we didn't even imagine when writing RFC 6343, yet it does
have stable, reliable DNS service ;-).

 and of course also:
  http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
  (though that technically expired).

3 years ago that seemed premature. With recent progress in real IPv6,
I'm wondering whether it isn't time to revive it. If so it should be
changed to be a BCP that says Don't do this and also makes
the proposed standard drafts Historic.

But we do hear persistently that there are happy hobbyist and peer to peer
users of 6to4. Using it offer web service for the Arizona Department of
Economic Security is so wrong, though.

From my reading of RFC6343 it is not clearly stated that one should not
 produce  records with 6to4 addresses.  The wording is unclear IMHO.

No, it is intended to say that if you insist on using 6to4, you *need*
stable DNS service and possibly reverse DNS.

   Brian

 
 Except for quick tests, doing anything with 6to4 is futile.


 Fully agree on that, 6to4 is the worst and the fact that it was not made
 historic is a shame.
 
 
 Clearly though in this case the address never worked. Can't fix problems
 between chair and keyboard with documents.


 Fair
 
 
 3.  Do no make  records with NAT64 WKP 64:ff9b::/96 ( saw this last
 week )
 One can stuff whatever one wants in DNS, if it breaks though that is the
 problem of the operator.

 Greets,
  Jeroen


 
 There in lies the problem.  I have received escalations in the last few
 days on my eyeball network regarding internet servers with 6to4 in DNS and
 NAT64 WKP in DNS.   In the WKP case, the server operator read the RFCs and
 tried to pursued me to his understanding of those RFCs that i should route
 and support WKP to my NAT64 and that he was doing the right thing by
 putting the WKP as RR in his DNS files.
 

Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Brian E Carpenter]

On 24/08/2014 09:20, Marco d'Itri wrote:
 On Aug 23, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
 
 Actually I think you should quibble. The issue isn't bad software
 used by intermediaries, it's that by design DMARC p=reject breaks a
 very common model used by intermediaries. Whether that is a bug or a
 feature in DMARC is out of scope for this thread, however.
 I was not referring to the mailing lists issue, which is not relevant 
 unless you also use DMARC with p=reject, but to broken MTAs which mangle 
 forwarded messages (look for DKIM validation failures and you will 
 easily find many).

Oh, OK, that wasn't obvious from the context.

   Brian

 There is a reason if DMARC was designed to use both SPF and DKIM.
 

Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818

[Brian E Carpenter]

On 23/08/2014 11:16, Dan Wing wrote:
 On Aug 22, 2014, at 7:42 AM, Matthew Huff mh...@ox.com wrote:
 
 Currently it is not feasible to do ipv6 reputation filtering. IPv4 
 reputation filtering is a big part of most anti-spam engines, so without it, 
 SPF / DKIM of domain reputation is the best alternative.

 BTW, we have had to remove all IPv6 from our mail gateways due to the large 
 number of Exchange SBS with broken isatap/6to4 tunnels causing mail to 
 blackhole.
 
 MTU issue?

I can't speak for Teredo, but for 6to4 there is a whole list of
possible issues ( http://tools.ietf.org/html/rfc6343 ). PMTUD failure
and/or MSS negotiation failure are on the list, and so is reverse
DNS failure.

   Brian

 
 -d
 
 
 These have been at small web based retailers which don't have hosted email. 
 After the third incident, we yanked our IPv6 from our MX/gateways.



 
 Matthew Huff | 1 Manhattanville Rd
 Director of Operations   | Purchase, NY 10577
 OTA Management LLC   | Phone: 914-460-4039

 -Original Message-
 From: ipv6-ops-bounces+mhuff=ox@lists.cluenet.de 
 [mailto:ipv6-ops-bounces+mhuff=ox@lists.cluenet.de] On Behalf Of Nick 
 Hilliard
 Sent: Friday, August 22, 2014 10:25 AM
 To: Lorenzo Colitti; Laurent GUERBY
 Cc: IPv6 Ops list
 Subject: Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam 
 since 20140818

 On 22/08/2014 15:16, Lorenzo Colitti wrote:
 Are you following the Additional guidelines for IPv6 section of
 https://support.google.com/mail/answer/81126 ?
 Lorenzo,

 it looks like Google is trying to enforce SPF / DKIM on ipv6 connections 
 where there is no similar requirement for ipv4.  Is there a particular 
 reason for this?  It's causing a lot of breakage.

 Nick

 
 

Re: IPv6 packets with HBH

[Brian E Carpenter]

You-all might want to hop over to IETF-land to comment on
http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering

Regards
   Brian

On 19/07/2014 07:45, Yannis Nikolopoulos wrote:
 Eric,
 
 thanks for your comments
 
 On 07/09/2014 12:47 PM, Eric Vyncke (evyncke) wrote:
 Yannis

 While I cannot speak for all vendors or even for all of my employer's
 products, you will indeed find that control-plane policing (=
 rate-limiting) is either on by default or can be configured on most
 routers.

 Alternatively, you may want to use plain ACL to drop all those
 potentially-harmful packets with HbH.

 You probably know that HbH is also used on the local link for MLD and on
 the WAN for RSVP (and possibly for other purposes). So, be sure to
 understand your own use before configuring drop/rate limiting ;-)

 Rate-limiting is really the way to go IMHO. A platform which processes
 HbH
 without rate-limiting (and there are such platforms) should NOT be
 deployed on the wild Internet.
 
 maybe I should forward this last comment (with which I agree) to our
 local Cisco team ;)
 
 cheers,
 Yannis
 
 Hope that this belated reply helps

 -éric


 On 5/07/14 15:27, Yannis Nikolopoulos d...@otenet.gr wrote:

 On 07/04/2014 11:43 PM, Brian E Carpenter wrote:
 On 05/07/2014 04:05, Yannis Nikolopoulos wrote:
 hello,

 how do people handle packets with HBH present? Since their use is a
 potential attack vector, do people rate-limit them? I can't seem to
 find
 some sort of best practice on the issue
 I have the impression that they are simply ignored in many cases.
 That is simpler than rate-limiting. It is legal, because we reduced
 the requirement to processing them to a SHOULD in RFC 7045:

  The IPv6 Hop-by-Hop Options header SHOULD be processed by
  intermediate forwarding nodes as described in [RFC2460].  However,
 it
  is to be expected that high-performance routers will either ignore
 it
  or assign packets containing it to a slow processing path.
 Designers
  planning to use a hop-by-hop option need to be aware of this
 likely
  behaviour.
 That sounds fine and it would make our lives easier but...

 I'm note sure about other vendors, but it seems that Cisco boxes are
 processing those at each node, at least it seems that ASR9k and 7600 do
 (although there's the option to rate-limit them). CRS probably rate
 limit them by default but the info is quite scarce

 cheers

- Brian

 cheers,
 Yannis

 
 

Re: IPv6 packets with HBH

[Brian E Carpenter]

On 06/07/2014 01:27, Yannis Nikolopoulos wrote:
 On 07/04/2014 11:43 PM, Brian E Carpenter wrote:
 On 05/07/2014 04:05, Yannis Nikolopoulos wrote:
 hello,

 how do people handle packets with HBH present? Since their use is a
 potential attack vector, do people rate-limit them? I can't seem to find
 some sort of best practice on the issue
 I have the impression that they are simply ignored in many cases.
 That is simpler than rate-limiting. It is legal, because we reduced
 the requirement to processing them to a SHOULD in RFC 7045:

 The IPv6 Hop-by-Hop Options header SHOULD be processed by
 intermediate forwarding nodes as described in [RFC2460].  However, it
 is to be expected that high-performance routers will either ignore it
 or assign packets containing it to a slow processing path.  Designers
 planning to use a hop-by-hop option need to be aware of this likely
 behaviour.
 That sounds fine and it would make our lives easier but...
 
 I'm note sure about other vendors, but it seems that Cisco boxes are
 processing those at each node, at least it seems that ASR9k and 7600 do
 (although there's the option to rate-limit them). CRS probably rate
 limit them by default but the info is quite scarce

It's for router vendors to comment, but the RFC is very recent so
it will be a while before we can expect products to be changed.
If everybody makes a feature request to their vendors along the
lines of option to disable HBH processing as allowed by RFC 7045
something might happen.

Brian

Re: IPv6 packets with HBH

[Brian E Carpenter]

On 05/07/2014 04:05, Yannis Nikolopoulos wrote:
 hello,
 
 how do people handle packets with HBH present? Since their use is a
 potential attack vector, do people rate-limit them? I can't seem to find
 some sort of best practice on the issue

I have the impression that they are simply ignored in many cases.
That is simpler than rate-limiting. It is legal, because we reduced
the requirement to processing them to a SHOULD in RFC 7045:

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

 - Brian

 cheers,
 Yannis
 

Re: So, time for some real action?

[Brian E Carpenter]

On 07/02/2014 04:48, Nick Hilliard wrote:
 On 06/02/2014 14:51, Dick Visser wrote:
 http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn-off-ipv4-on-6-june-2014-for-one-day/
 
 This is a terrible idea which will cause IPv6 to be associated with
 gratuitous breakage.

That was my first reaction, but It’s all voluntary – you can turn off IPv4
on your own devices, but no one will be turning off IPv4 for anyone else.
doesn't sound quite that bad; only geeks will do that, and probably only for
about 5 minutes. So it's probably a cute idea.

I see a button here for turning of the loudspeaker, and another one
for Bluetooth, but I can't seem to find the EyePeeVeeFour button.

Brian

Re: Question on DHCPv6 address assignment

[Brian E Carpenter]

It's also worth noting that the old presumption that MAC-based
interface identifiers are normal and anything else is strange is
obsolete. See http://tools.ietf.org/html/draft-ietf-6man-ug-06
which is approved in the RFC queue already and
http://tools.ietf.org/html/draft-ietf-6man-default-iids-00
for a possible future recommendation.

These documents are mainly written with SLAAC in mind rather
than DHCPv6, but I don't think that changes the principles.
Personally I would avoid sequential range like fd00::1, fd00::2
because it exposes you to easy scanning attacks. Random seems
best except for servers.

Regards
   Brian Carpenter

On 02/02/2014 09:18, Henri Wahl wrote:
 Hi,
 
 1) What's the pattern with which addresses are generated/assigned? Are
 they sequential (fc00::1, fc00::2, etc.)?  Random? Something else?

 We use our dhcpy6d (http://dhcpy6d.ifw-dresden.de) which allows 4
 different address categories:
 - sequential range like fd00::1, fd00::2
 - completely random /64 like with privacy extensions:
 fd00::3d2a:563f:76f1:d94f
 - plain MAC address like fd00::2034:d4f1:439a
 - some arbitrary id number given in client configuration like fd00::1,
 fd00::3421
 
 See http://dhcpy6d.ifw-dresden.de/documentation/config/addresses for
 details.
 This way one can hand out for example 2 addresses to clients, one random
 privacy-aware global and one range or MAC-based for internal use. The
 bad news is that only Windows 7+ is capable of handling more than one
 address given by DHCPv6 out of the box. Linux has to be tweaked not to
 use Network-Manager and MacOS fails completely - maybe would work with
 some dhclient or dibbler-client.
 
 2) What about their stability? Is there any intent/mechanism for them to
 be as stable as possible? Or is it usual for hosts to get a new
 address for each lease?
 
 MAC and ID based addresses are of course stable, the range based ones
 intend to be too and the random ones are regenerated whenever a lease
 expired.
 
 Best regards
 Henri
 
 

Question about IPAM tools for v6

[Brian E Carpenter]

Hi,

We're working on the next version of
http://tools.ietf.org/html/draft-carpenter-6man-why64

Can anyone say whether existing IP Address Management tools that
support IPv6 have built-in assumptions or dependencies on the
/64 subnet prefix length, or whether they simply don't care about
subnet size?

Regards
   Brian

Re: Question about IPAM tools for v6

[Brian E Carpenter]

On 30/01/2014 11:19, Cricket Liu wrote:
 Hi Mark.
 
 On Jan 29, 2014, at 11:07 AM, Mark Boolootian boo...@ucsc.edu wrote:
 
 Can anyone say whether existing IP Address Management tools that
 support IPv6 have built-in assumptions or dependencies on the
 /64 subnet prefix length, or whether they simply don't care about
 subnet size?
 We use Infoblox's IPAM.  There aren't any limitations of which I'm
 aware in terms of allocating space and IPv6 prefix length in the IPAM.
 However, I don't know if there are restrictions when it comes to
 DHCPv6, as we've only set up /64s.
 
 Consensus around here is that we support DHCPv6 for non-/64 subnets 
 (particularly in the context of Prefix Delegation), but the immediate next 
 question is Why would you need that?

That's been a reasonably hot topic over on the IETF v6ops list,
which is what prompted a group of us to start writing a draft
(which we want to make fact-based, not opinion-based, hence
my question here).

Thanks to you and the others who have replied with facts!

Brian

Re: Anybody else unable to reach sixxs.net?

[Brian E Carpenter]

Thanks to those who replied on and off list. It seems
to be a local routing hole so I have contacted the ISP.

Regards
   Brian

On 18/01/2014 16:33, Brian E Carpenter wrote:
 C:\windows\system32tracert www.sixxs.net
 
 Tracing route to nginx.sixxs.net [2620:0:6b0:a:250:56ff:fe99:78f7]
 over a maximum of 30 hops:
 
   1 1 ms 1 ms 1 ms  fritz.box 
 [2406:e000:e012:1:be05:43ff:fe8e:ce39]
   214 ms22 ms13 ms  2406:e000:97:1::1
   3 *** Request timed out.
   4 *** Request timed out.
   5 *** Request timed out.
 snip
  29 *** Request timed out.
  30 *** Request timed out.
 
 Trace complete.
 

Re: Reaching google.com using Chrome

[Brian E Carpenter]

On 14/01/2014 10:21, Justin Krejci wrote:
 Also when troubleshooting HTTP connectivity in general but can be really help 
 when dealing with a transition from IPv4 to IPv6 if you install the browser 
 extension IPvFoo for Chrome (IPvFox for Firefox) it can take out a 
 significantly complicated step in the troubleshooting process as it easily 
 shows you all of the IP addresses (v4 and v6) being connected to on any given 
 page and which are SSL and or non-SSL as well. It's very small and quite 
 useful.

Thanks for that - nicer than ShowIP on Firefox. If you're running ShowIP, you 
need to
disable it when installing IPvFox.

   Brian

 
 From: ipv6-ops-bounces+jkrejci=usinternet@lists.cluenet.de 
 [ipv6-ops-bounces+jkrejci=usinternet@lists.cluenet.de] on behalf of 
 Jeroen Massar [jer...@massar.ch]
 Sent: Monday, January 13, 2014 12:13 PM
 To: Sammer Mati; ipv6-ops@lists.cluenet.de
 Subject: Re: Reaching google.com using Chrome
 
 On 2014-01-13 19:02 , Sammer Mati wrote:
 [..]
 We ran wireshark and found out that the IPv6 address is different for
 Google.com when using IE or Chrome! I haven't tested yet with Windows7
 
 That is just pure DNS selection luck...
 
 Note that a lot of properties on this massive Internet are using
 Geo-DNS, load-balancing, BGP-based routing tricks/anycasting and a lot
 of other nasty funny tricks.
 
 Hence, as you did not include any traceroute or other data, little else
 anybody can say...
 
 Greets,
  Jeroen
 
 

Re: Best practice - dual stack DNS?

[Brian E Carpenter]

What about http://tools.ietf.org/html/rfc6106 ?

   Brian

On 22/10/2013 01:24, Roger Wiklund wrote:
 Hi.
 
 I'm setting up a wireless guest network with dual stack.
 Private IPv4 via DHCP and public IPv6 via SLAAC.
 
 At first had the client first hop IPv6 routing on the WAN CPE using SLAAC
 and DHCPv6 just for DNS.
 
 I decided to move the client first hop IPv6 routing to the ASA firewall
 instead, but it does not support DHCPv6.
 
 So currently I only have IPv4 DNS and what works just fine. What's the best
 practice for dual stack DNS? Should I bother with setting up DHCPv6 relay
 etc?
 
 Thanks!
 
 /Roger
 

Re: teredo.ipv6.microsoft.com off?

[Brian E Carpenter]

On 19/07/2013 22:15, Tim Chown wrote:
 On 19 Jul 2013, at 10:34, Phil Mayers p.may...@imperial.ac.uk wrote:
 
 On 07/18/2013 09:09 PM, Brian E Carpenter wrote:

 Wait... I had the impression that iff there was no other IPv6 connectivity,
 Teredo was used in older Windows because of the generic prefer IPv6 rule.
 The default RFC 3484 table covers 6to4 but not Teredo.
 AFAIK, every version of windows (i.e. Vista, 7, 8) that comes with Teredo 
 also comes with a de-pref rule for it, not just recent versions.

 Put another way, Teredo should never be preferred over IPv4, because all 
 versions of Windows with Teredo use extended RFC 3484 rules.

 Most of the Teredo activity we see is when IP addresses are used directly 
 (i.e. no getaddrinfo). For example, BitTorrent connections where peers were 
 looked up in DHT/PEX. In these cases, an IPv6 address will be connected to 
 over Teredo if there's no other connectivity.
 
 Again, my understanding is the same as Phil's here.

I think my recollection is of Teredo with Windows XP SP2. But I
could be wrong, of course. In any case, the case for phasing out
Teredo is strong, like the case for disabling client-side 6to4.

   Brian

 Many vendors/implementors started adding rules that ultimately appeared in 
 RFC6724 long before RFC6724 was published.  It took 6 years(!) for that 
 update to be completed through the IETF.   
 
 There are however some platforms stuck on 3484 or that don't follow such 
 rules (Mac OSX is an interesting one...)
 
 Tim
 
 

Re: teredo.ipv6.microsoft.com off?

[Brian E Carpenter]

On 17/07/2013 19:13, Ignatios Souvatzis wrote:
...

 Let me ask one thing... a couple of years ago, when I read the
 specification of Teredo, I was quite impressed by the details (If
 you accept the premise that you have to work around being jailed
 behind an IPv4 NAT) put into the protocol. One detail was that it
 is supposed to be lowest priority and so go automatically away
 (from the client end) as soon as some configued IPv6 is available
 on the link.
 
 Isn't that how it's implemented?

Yes, but the result is that the host tries to use Teredo preferentially
even if the IPv4 path is better; and if the Teredo path is broken
the result is user pain (as with 6to4). I think the idea of deprecating
Teredo is that now that native IPv6 is a serious option, the costs of
Teredo outweigh the benefits,on average.

(Unfortunately nobody ever wrote the Teredo equivalent of RFC6343.)

Brian

Re: same link-local address on multiple interface and OSPFv3

[Brian E Carpenter]

On 29/06/2013 22:18, Benedikt Stockebrand wrote:
 Hi Phil and list,
 
 [Using the same link-local address on multiple (VLAN) interfaces]

 Many routers wouldn't let you do that in IPv4. Cisco IOS doesn't, for
 example:
 
 IPv4 doesn't have link-local addresses or anything similar (unless you
 want to consider 192.169/16 similar in this context).

Of course not, but I was trying to see how deep in the product
design the issue might go. It sounds like dumb copying of the IPv4
logic (where as Gert says there is no implied scope and therefore
a real ambiguity).

Brian

Re: Point-to-point /64

[Brian E Carpenter]

On 03/06/2013 10:06, Steinar H. Gunderson wrote:
 2013/6/2 Brian E Carpenter brian.e.carpen...@gmail.com:
 I'm not sure about other switches, but for the Catalyst 3750/3750G, it
 means some quirks with IPv6 ACLs.  The 3750/3750D can do ACLs on full
 /128's, but only if the lower 64 bits are EUI64.
 Huh? How can it possibly know that? (see draft-ietf-6man-ug)
 
 Presumably he means that the middle bits are ff:fe.

And the UG bits are 10. But none of that proves that the identifier
is EUI64. It only proves that it *might* be EUI64.

   Brian