Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Bill Jouris writes:
> --===============0047193473602130639==
> Content-Type: multipart/alternative; boundary="1510626085-1351415829-1376330247=:41781"
> 
> --1510626085-1351415829-1376330247=:41781
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable

Bill replace your MUA with one that DOES printed-quotable CORRECTLY.
This garbage is not correct.
 
> > From: Owen DeLong <[e-mail]>=0A> To: Mark Andrews <[e-mail]> =
> =0A> Cc: Alejandro Acosta <[e-mail]>; [e-mail] =0A> Sen=
> t: Monday, August 12, 2013 10:00 AM=0A> Subject: Re: [v6ops] draft-moreiras=
> -v6ops-rfc3849bis-00=0A =0A>=0A>> =0A>> All a documentation prefix will do =
> is have one potentially toxic=0A>> prefix compared to a handful of potentia=
> lly toxic prefixes.=A0 There=0A>> are 1099511627776 prefixes in fd00::/8.=
> =A0 Even if there were thousands=0A>> of documentation prefixes the odds of=
>  you hitting one when generating=0A>> your own prefix are astronomically sm=
> all.=A0 Additionally the more=0A>> prefixes that are used in documentation =
> the less toxic a particular=0A>> prefix will be.=0A=0A> No, it will also he=
> lp to constrain such errors to an easily identifiable single=0A> prefix whi=
> ch will make the errors easier to identify and correct. This is, IMHO,=0A> =
> a worth while goal in the real world where operators actually run networks=
> =0A> and have to deal with less than ideally trained predecessors and colle=
> agues.=0A>=0A> Owen=0A=0AOne other thing: if you have a single documentatio=
> n prefix, you can actually build that knowledge into your firewalls and rou=
> ters -- meaning that anyone who does a copy without change will immediately=
>  find that his addresses simply don't work.=A0 Making that particular error=
>  essentially self-correcting,=0A=0ABill Jouris=0AInside Products, Inc.=0Aww=
> w.insidethestack.com=0A831-659-8360=0A925-855-9512 (direct)=0A

> > From: Owen DeLong <[e-mail]>
> > To: Mark Andrews <[e-mail]>
> > Cc: Alejandro Acosta <[e-mail]>; [e-mail]
> > Sent: Monday, August 12, 2013 10:00 AM
> > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
>
> >
> >>
> >> All a documentation prefix will do is have one potentially toxic
> >> prefix compared to a handful of potentially toxic prefixes.  There
> >> are 1099511627776 prefixes in fd00::/8.  Even if there were thousands
> >> of documentation prefixes the odds of you hitting one when generating
> >> your own prefix are astronomically small.  Additionally the more
> >> prefixes that are used in documentation the less toxic a particular
> >> prefix will be.
>
> > No, it will also help to constrain such errors to an easily
> identifiable single
> > prefix which will make the errors easier to identify and correct. This
> is, IMHO,
> > a worth while goal in the real world where operators actually run
> networks
> > and have to deal with less than ideally trained predecessors and
> colleagues.
> >
> > Owen
>
> One other thing: if you have a single documentation prefix, you can
> actually build that knowledge into your firewalls and routers -- meaning
> that anyone who does a copy without change will immediately find that his
> addresses simply don't work.  Making that particular error essentially
> self-correcting,

For Locally Assigned ULA you default to filtering *all* prefixes.
ULA is not the same as GUA.  You can't just plug sites together
without *first* checking for collisions in ULA space like you can
with GUA.  It is a recipe for disaster if you don't check.

A-B-C-A will work if you just want to talk to your direct neighbors.
If it is a federation you need to get one or both of the A's to
renumber and you also need someone/thing to ensure uniqueness within
the federation.

> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> 831-659-8360
> 925-855-9512 (direct)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]