Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations

["Dale W. Carder" <[e-mail]>]

Thus spake Fernando Gont ([e-mail]) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
> 
> * Section 3.2: Do folks really generate the prefixes as "required"?
> Me, I confess I've used things like fc00:1::/64 because they are simpler
> that some random string of bits.

I absolutely do not believe it can be expected that sites will generate 
random prefixes.   This will result in more NAT and all of the horror
stories from rfc1918 getting copied over.  For a while someone (SixXS?)
was running a ULA registry, but I am not sure what came of it.

In 5.1, the last paragraph states "Another important difference is the 
ability to merge two ULA networks without renumbering (because of the 
uniqueness), which is a big advantage over [RFC1918]."  So, should 
section 5.1 emphasize the importance of this uniqueness, or could 
this fit better somewhere else?

> * Section 4.2.2, page 9:
> > 
> >    o  DNS relevant: if administrators choose not to do reverse DNS
> >       delegation inside of their local control of ULA prefixes, a
> >       significant amount of information about the ULA population may
> >       leak to the outside world.  Because reverse queries will be made
> >       and naturally routed to the global reverse tree, so external
> >       parties will be exposed to the existence of a population of ULA
> >       addresses.  [ULA-IN-WILD] provides more detailed situations on
> >       this issue.  Administrators may need a split DNS to separate the
> >       queries from internal and external for ULA entries and GUA
> >       entries.
> 
> This text seems to imply that someone will do reverse mappings for ULAs.
> Could you please elaboate a bit on the scenario that you envision?

I thought rfc4193 section 4.4 covered DNS adequately, but I think the
claim here is that the recommendations won't be followed (notice a
theme?).  If a site doesn't (or can't) follow them, the recommendation
is to at least run with split dns views to mitigate.

Dale