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
>

>>>
>>
> 

IOS 10 (?) and IPv6-only WLAN

[Bernhard Schmidt]

Hi,

for a couple of years now we have been running an IPv6-only eduroam on
Campus for testing purposes. We use the following setup

- VLAN terminated on Cisco N7k
- wireless clients can't talk to each other
- no IPv4 at all on the network (blocked by Wireless ACLs)
- /64 SLAAC, on-link flag in RA not set
- O-bit set in RA (stateless DHCPv6)
- DHCPv6 relay to ISC DHCP, handing out a dedicated DNS64 resolver
- DNS64 resolver on BIND 9.9, with our own network specific NAT64 prefix
(not 64:ff9b::/96)
- NAT64 gateway with Tayga on Linux

The setup works quite well Linux, Windows (as well as NAT64/DNS64
without 464XLAT works). It doesn't work on Android due to lack of DHCPv6
of course. I think I had tested it with IOS 9.something and it worked
there as well.

Today we've received a report that IOS 10 devices cannot use it. I tried
myself with an iPad running IOS 10.0.2 and I'm unable to use it either.

- device does not show any errors about internet connectivity
- device configures two IPv6 addresses and router from RA
- device receives DNS64 nameserver from stateless DHCPv6
- device eventually configures an autoconf IPv4 address (169.254.x.x)
without a gateway
- I see A/ DNS queries to the DNS64 server
- neither IPv4 nor IPv6 nor dualstacked websites work, the browser just
times out. I cannot see any network activity of the device (but it's
hard to tell, since I'm currently at home)

I don't have an older iOS device to crosscheck.

Does anyone have any ideas what could be wrong?

Bernhard

Re: Linux and ULA support and default route

[Jeroen Massar]

On 2016-10-13 09:36, Tore Anderson wrote:
> * Jeroen Massar 
> 
>> RA's only install the /64 and when default announced a default.
>>
>> Thus 'the rest of the ULA /48' would require a default route to be
>> installed to reach that...
>>
>> When the device does not install a default route, there won't be an
>> entry for anything in that /48, just the /64 and thus that space won't
>> be reachable.
> 
> Not if you set the accept_ra_rt_info_max_plen sysctl to >= 48 (and the
> router implements RFC 7084 L-3).

Which is why looking at the exact RA is important.

> As far as I know, this sysctl is 0 by
> default which causes the kernel to ignore RIOs.

Correct. See among st others here for reasoning:
https://patchwork.ozlabs.org/patch/331802/

and as it is default 0, unless one does already salt/puppet/etc to
change that default, it won't easily get deployed; and if one does
salt/puppet/etc then adding static routes can also work.

Much easier and better to let the actual routers decide on routing
though and not end-hosts.

> I believe that Windows do accept RIOs by default so that's probably why
> it worked for Brian. NetworkManager user-space RA processing will also
> respect RIOs by default.

Only silly people run broken software like "NetworkManager" ;)

Greets,
 Jeroen

Re: Linux and ULA support and default route

[Jeroen Massar]

On 2016-10-13 02:30, Brian E Carpenter wrote:
> 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).

RA's only install the /64 and when default announced a default.

Thus 'the rest of the ULA /48' would require a default route to be
installed to reach that...

When the device does not install a default route, there won't be an
entry for anything in that /48, just the /64 and thus that space won't
be reachable.


Btw: IMHO ULAs are in 99% of the cases the wrong thing to use anyway.
But note, this is not specific to ULA at all. (Except maybe that your
device chose to not push a default route, as there is no default route
to the Internet).

You might want to check with tcpdump with the exact details of the RA are.

Greets,
 Jeroen