Re: [v6ops] reclassify 464XLAT as standard instead of info

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ole Troan writes:
>
> >>>> From my perspective, there are multiple interoperable specs. We have
> >>>> several CLAT client implementations/vendors, from different vendors, and
> >>>> they work fine in the same and different operators and interoperate with
> >>>> different NAT64 and DNS64 vendors/implementations.
> >>>
> >>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) +
> >>> RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are
> >>> already Standards track, if we need also to move them to STD in that
> >>> case, etc.
> >>
> >> I'll repeat myself earlier. Looking at the definitions of the terms,
> >> there is no reason it can't or shouldn't be BCP, which our charter does
> >> allow us to do, and which is a one-shot standard more appropriate to the
> >> case (IMHO). If you want it to be a standardard, a BCP is a standard.
> >> Let's advance it to BCP.
> >
> > I think there’s an argument for this.
> >
> > But there will be people who will argue that encapsulation is the
> > ‘best’ practice.  Is there scope for a BCP by translation and a BCP by
> > encapsulation?  Or would the BCP say NAT64/DNS64/464XLAT is the best way
> > to serve nodes in an IPv6-only network?
> >
> > With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we
> > ended up with many varieties, with different properties. There’s an
> > argument also I think to nail down one single best translation approach.
>
> Yes, I do wonder in what alternate universe the IETF consensus is that
> best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)
>
> Ole

Hopefully not this one.  Just because there is a $billion company
doing something it doesn't make it best practice.

There is also plenty of PD-Lite out there which has none of the
side effects of NAT46 + NAT64 + DNS64.

Mar 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]