Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Simon Hobso
n writes:
> Fred Baker <[e-mail]> wrote:
>
> >
> > On Jun 7, 2017, at 4:42 PM, james woodyatt <[e-mail]> wrote:
> >> As far as I know, nobody associated with Thread apart from me is even
> >> listening to IETF much less offering anything to say. And the only thing
> >> I'm saying is that IETF should stop pretending that IPv6/NAT in end site
> >> addressing plans is preventable. It's inevitable.
> >
> > That's not LACNIC's experience. They have been testing to see what the
> > real story is - put an ad in a web page that accesses a STUN server, and
> > reports whether the addresses are the same or different. What they find
> > is that, in Latin America, IPv4 hosts have a 94% probability of being
> > behind a NAT, but IPv6 hosts have only a 0.6% probability.
> >
> > Just saying... Last I checked data trumps opinion.
>
> Well said.
> I also can't see how anything good can come of an attitude that "people
> will do it, so lets drop any standards/best practice statements saying it
> shouldn't be done". Taking that to an extreme, you could say that [CG]NAT
> solves the IPv4 addressing problem so why do IPv6 at all !
>
> I can well believe that most IPv4 traffic involves NAT. NAT is the
> band-aid that's kept IPv4 going for the last decade or two, and without
> it, most users would not get online at all.
> As others have said, there's no need for any form of address translation
> in IPv6 **other than due to operator shenanigans**. If there are
> established standards that say "thou shalt do xxx" and "thou shalt not do
> yyy" then there is something for customers to beat up the more idiotic
> service providers and give them some incentive to fix things. It might
> help if software developers, instead of spending time on workarounds,
> simply (or at least, start with) put up a warning to the user that their
> IPv6 network is broken according to RFCblah and only then offer to carry
> on with a "best effort" attempt to work around it.
>
> If support forums for packages have threads which come down to "complain
> to your ISP that they don't comply with RFCblah" then that will get a
> support loading for the ISP that the bean counters will see as a cost
> they can remove. Ie, make it more expensive for them to try the sort of
> tricks (like "you only get a nobbled IP allocation unless you pay us
> business rates") so there's a commercial incentive for them to do the
> right thing.
>
> My very limited experience with ISP provided IPv6 is that so far, what
> I've seen is sensible allocations (eg a /56 for a home user). If the
> majority do the right thing, then the exceptions can stand out and get a
> reputation for "broken". I know in the real world there will be cases
> where there's an effective monopoly (for some group of users) allowing
> the ISP to do what they want, but that's not an excuse to just throw in
> the towel and give the rest carte blanch.

And 256 prefixes very quickly become too few as we develop new
technologies to take advantage that you can get prefixes easily.
ISP's have been short sighted here.  The IETF started out saying
/48 to give every site enough prefixes that they shouldn't have to
go back and get more except in exceptional circumstances.

Note: the rule always has been "if you don't have enough prefixes
ask your ISP for more".  DHCP-PD allows for this, you can us DHCP-PD
to request additional blocks.  RIR's allow ISP's to get more addresses
to support this.

Mark

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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