Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Liubing (Leo) <[e-mail]>
> To: Shishio Tsuchiya (shtsuchi) <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Monday, 30 June 2014 2:10 PM
> Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2
> 
> Hi Shishio,
> 
> Thanks much for sharing the information. It's great that JANOG34 will 
> provide more experience of using ULAs.
> 
> Basically I agree with Fred that it is important to see whether the statements 
> of the draft is correct. In addition to Fred's comments, I have some other 
> concerns:

So I added a ULA /64 to my home network in addition to my ISP assigned GUA /64 in around May last year IIRC, so see if it would cause any problems. I generally try to be a 'user' at home so that I can get some insight into what the typical non-technical person experiences.

I haven't had any issues since adding the ULA, which could mean any of (a) the ULA is never used, (b) the right choice is being made between the ULA and GUA prefix, and (c) happy eyeballs is hiding any IPv4 vs IPv6 ULA issues. Not very scientific, but then again there has never been any issues which has made me consider the ULA prefix to be a possible cause. I have for somewhere in the order of the last six months switched off the RA PIO L bit for both my GUA and ULA prefix to see how hairpinning all traffic except link-local through my default router works, and have also not really noticed anything, other than Linux Network manager taking over IPv6 configuration from the kernel, and not obeying the RA PIO L bit (which should be fixed now).


> - Is it easy to configure a host with ULA+PA? E.g., both through SLAAC

Yes. I'm using OpenWRT on my CPE, I added the ULA prefix via the 'luci' gui. It is now an additional RA PIO, and I'm using SLAAC addressing, so my hosts get both GUA and ULA prefixes/addresses (and temporary addresses as well, as I've also enabled that).

> or 
> through SLAAC/DHCPv6 respectively.

Don't know about DHCPv6.

> - Are there still many hosts using the old address selection algorithm [3484]? 
> Since [RFC3484] hosts will face the problem of selecting un-expected ULA-PA 
> source/destination address pairs.

Either yes, or most likely. My 'normal' or commonly used hosts are Linux (currently Fedora 20, 3 of them), and for a while I was updating /etc/gai.conf with the new RFC6724 rules. However I haven't got around to doing that for the most recent Fedora 20 installs, so I think it is likely that those hosts are still using RFC3484 rules for the last six months.

I do have some virtual windows hosts, however I haven't looked closely at them in this regard. My Android phone is has both GUA and ULA addresses (and privacy addresses for both GUA and ULA prefixes), and I've had no issues with using that. I recently got a Chromecast which can use IPv6 to stream content, and it doesn't seem to have had any issues with the ULA prefix when accessing GUA IPv6 only available content.

The ULA vs GUA rules in RFC6724 only really matter if there is a choice between a GUA and a ULA. ULAs shouldn't be in the global DNS, so in most cases there will be no choice, it'll either be one or more GUAs or one or more ULAs exclusively.

Some people seem to be concerned about ULAs being put in the global DNS, and therefore causing problems if a host tries to use an unreachable ULA instead of a reachable GUA address. In my experience I haven't seen that problem occur with RFC1918s in global IPv4 DNS entries, so I don't think it will happen much with IPv6 ULAs. That being said, I think the Happy Eyeballs approach applied to the set of returned IPv6 addresses, which might be a mix of GUAs and ULAs, not just across IPv4 and IPv6 addresses would mitigate that.

> - Let me confirm the ULA-only Deployment in JANOG34, did you mean "connect 
> to the Internet through ULA-only" or "ULA-only in an isolated network 
> or for internal use only"? (The 3.2.1 of the draft specifically means the 
> former.) 
>

These questions sound a bit to me like you haven't added a ULA prefix to an IPv6 network you're commonly using. So if you haven't, I think you should - 'the proof of the pudding is in the eating'.

Regards,

Mark.
  
> Best regards,
> Bing
> 
> 
>>  -----Original Message-----
>>  From: Fred Baker (fred) [mailto:[e-mail]]
>>  Sent: Saturday, June 28, 2014 8:58 AM
>>  To: Shishio Tsuchiya (shtsuchi)
>>  Cc: Liubing (Leo); [e-mail]; [e-mail]; [e-mail]
>>  Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2
>> 
>> 
>>  On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya <[e-mail]> 
> wrote:
>> 
>>  > Leo and v6ops
>>  > F.Y.I
>>  > JANOG(JApan Network Operator's Group) decided to provide ula 
> address
>>  to the JANOG34 conference network.
>>  > http://www.janog.gr.jp/en/index.php?JANOG34_Meeting
>>  >
>>  > They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along with
>>  GUA.
>>  >
>>  http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02
>>  >
>>  > If you would like to confirm something on the network , please let me
>>  know.
>> 
>>  Thanks for this.
>> 
>>  I would expect that the key things to prove are the statements in the 
> draft.
>>  Also, any observations that might come up would be useful. For example,
>>  was it fair to say that the network that was isolated remained isolated? 
> Did
>>  using a ULA and a GUA on a globally-accessible network cause any issues?
>>  What, if anything, was necessary in the router(s) in question to prevent 
> hosts
>>  from using ULA source addresses to connect to GUA addresses? Did hosts in
>>  fact form both ULA and GUA-based addresses and use them appropriately
>>  when connecting to applications inside and outside the network?
>> 
>>  What one might hope would be that ULA-based addresses were used to
>>  connect to other ULA-based addresses, as their bit strings were most 
> similar,
>>  and GUA-based addresses were used to connect to other GUA-based
>>  addresses, for the same reason. One might hope that ULA prefixes were not
>>  announced in BGP without needing extra thought, and that if they were
>>  announced, they were not accepted. One might further hope that when a
>>  ULA was not announced into a neighboring domain, a packet sent to the ULA
>>  prefix didn't cross the domain boundary.
>> 
>>  Of course, we need to hear about any extra work that was required, and any
>>  problems that arose. And we need to understand if the deployment of a ULA
>>  prefix necessarily implied the deployment of an IPv6/IPv6 NAT or NAPT. I
>>  don't expect that it will and am certainly not asking for it to, but 
> that
>>  expectation has been promoted.
>> 
>>  JANOG will be Wednesday-Friday the week before IETF 90, and v6ops will
>>  meet Monday and Tuesday. It would be nice if someone could make a point
>>  of reporting on the experiment.
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>