Re: [v6ops] A good example of why we need to careful about ULAs

In message <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com>, Mark S
mith writes:
> 
> >Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>; "draft-ietf-v6ops-ula-usage-reco=
> mmendations@tools.ietf.org" <draft-ietf-v6ops-ula-usage-recommendations@too=
> ls.ietf.org> =
> 
> >Sent: Thursday, 30 May 2013 7:07 PM
> >Subject: Re: [v6ops] A good example of why we need to careful about ULAs
> > =
> 
> >
> >
> >On Thu, May 30, 2013 at 5:11 PM, Mark Smith <markzzzsmith@yahoo.com.au> wr=
> ote:
> >In the early news, not really a new problem.
> >>
> >
> >
> >The part where an RFC asserts says that we can generate globally unique ad=
> dresses with no global coordination is a new problem. Yes, in theory it wor=
> ks, but in practice it doesn't, because everyone ends up using fd00:: - bec=
> ause that's the way it worked in IPv4, and ULA is just RFC1918 all over aga=
> in, right?
> >
> 
> I don't agree with trying to create a registry for the non-centrally assign=
> ed ULAs (because I think those people probably think they now own that pref=
> ix), however here is quite a list to show that a lot of people from a varie=
> ty of organisations get that ULAs aren't set to fd00::/8

All locally assigned ULA are in fd00::/8.  I think you meant
fd00:0000:0000::/48.  Yes I deliberatly added the extra zeros make
it clearer.

The example that started this thread was not in fd00:0000:0000::/48.
They may not have configured their border routers to block traffic
to/from fc00::/7 and their router may not have appropriate source
address selection rules for the reply.  Both of those are correctable.

fd00:3303:0000::/48 may not *look* random but it may well be random.

> http://www.sixxs.net/tools/grh/ula/list/
> 
> 
> >
> >The key point here is that people are going to assume is that ULA is like =
> RFC1918 and we should carefully document all the ways in which it isn't.
> >
> 
> Agree with documenting it. Site-locals were "fd00::". The site-local deprec=
> ation RFC is pretty much the inverse of all the ways ULAs aren't site-local=
> s and RFC1918s.
> 
> >
> >So is this draft aiming for BCP status and therefore should only reflect b=
> est common practice?
> >
> >
> >I think documents coming out of v6ops should reflect scenarios where there=
>  is operational experience. I don't think v6ops is the place to say "here's=
>  what we could build". It's the place to say "here's what we've built; here=
> 's what works, and here's what doesn't".
> >
> >
> 
> >As an example: we've already discovered one of the use cases in this draft=
>  (the "use ULA as a pref64") is not a use case after all, because it causes=
>  devices to prefer IPv4 transition technologies like 464xlat over NAT64. We=
>  didn't know this because nobody had actually tried to *operate a network* =
> in such a use case. I happened to catch that one because I wrote and tested=
>  an implementation, but who knows if there are caveats in any of the others?
> >
> >
> >If as an operational group we publish guidance to operators that doesn't w=
> ork in the real world (like the pref64 case above), it will be embarrassing=
>  for us and wasteful of operators' time. We should strive to do better than=
>  that.
> >
> >
> 
> Ok. So then a follow up question is how to provide perhaps more tutorial or=
> iented information? RFCs, quite reasonably, provide enough information to j=
> ustify what is=A0proposed, and usually one use case, but not all of them. T=
> hat may not be enough information for more of a novice fully understand the=
>  problem that is being solved, the variety of opportunities to use it, and =
> the pros and cons of the use of what is proposed in those scenarios. I have=
> n't thought v6ops was just a place to document what has been done, but rath=
> er to document any topics related to operations, including advice and more =
> information on how things invented here and in other IPv6 working groups co=
> uld be used.
> 
> Regards,
> Mark.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org