Re: [v6ops] Apple and IPv6, a few clarifications - 64share

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Owen DeLong write
s:
>
> >>> It is better to tell the operator to provide a /63 to smartphones
> >>> (not a /64), with DHCPv6 Prefix Delegation.  That will fix it.
> >>
> >> No...
> >> If you're going to go to PD, a /63 is stupid. Ideally, use a /48,
> >
> > Well, one cellular network operator has a /47 to 'share' with all its
> > customer UEs.  If that operator gave a /48 to an UE it could satisfy
> > only 2 such customers, not millions.
>
> That is a problem that is easy to solve with a simple interaction with
> their RIR.
>
> Give me a break.
>
> We should not be designing around providers that didn't ask for enough
> IPv6 space for their deployments. We should educate those providers.
> IPv6 space is easy to get. A cellular network is an ISP almost by definition.
>
> There isn't a single RIR on the planet that won't grant you at least a /32
> if you walk up and say "I'm an ISP, /32 please" in any credible way.
>
> (modulo payment of fees, etc., but you get the point)
>
> >> but at least provide enough subnets to cover BT, USB, 2.4, and 5Ghz
> >> plus some headroom for future applications.
> >
> > I agree, headroom should be provided.
> >
> >>>> *) Internet Sharing on the Mac Today, regular internet sharing
> >>>> (from your ethernet to Wi-Fi for example) does not support IPv6
> >>>> because of the limited use cases, and the lack of demand for it.
> >>>
> >>> If you get done the above then you get Internet Sharing on the Mac
> >>> Today as well, for free.
> >>
> >> Since iOS and OSX  are separate code bases, I'm not sure why you
> >> think that.
> >
> > Because the DHCPv6 Prefix Delegation is a userspace application
> > implementing a protocol - suffices it to compile on each of these
> > code bases.  It acts the same everywhere.
>
> Yes and no.
>
> > It's not a GUI, or some kernel module, or some AF-dependent software.
>
> Well...
>  It is actually AF-dependent. DHCPv6 will not work on IPv4 very well at
> all.
>
> >>>> *) Internet Sharing on the Mac - NAT64 testing mode The NAT64
> >>>> test mode was designed to help developers ensure that their app
> >>>> can still function with IPv6-only NAT64+DNS64 connectivity and
> >>>> communicate with their IPv4 server, even if the developer does
> >>>> not have access to the IPv6 internet. That NAT64 network does
> >>>> not have IPv6 connectivity to the global IPv6 internet. As such,
> >>>> the current version advertises addresses from 2001::/64 instead
> >>>> of ULAs to simulate real IPv6 connectivity, as all IPv6 packets
> >>>> are terminated at the NAT64 server on the Mac. This
> >>>> implementation detail could change in the future.
> >>>
> >>> Makes sense.
> >>>
> >>
> >> Not really...
> >>  This address is currently in the IANA free pool. It
> >> could be assigned to an RIR and then put on a real network at any
> >> point in the future.
> >>
> >> It would be much better to use a /64 Apple can set aside from their
> >> own space or some other block of addresses registered for this
> >> purpose...
> >>  Heck, worst case, Apple could sign up for a free tunnel
> >> from HE and burn the /64 assigned to that tunnel.
> >>
> >> Ideally, the prefix should be user configurable as well.
> >
> > I think I didnt read the message as you did.
> >
> > I assume by 2001::/64 is meant actually 2001::/3, or some other
> > 2001:X:Y:U:Z::/64 that the operator prodived.  I think it was said
> > 2001::/3 to distiguish from ULA fd00::/something, and so I said it made
> > sense.
>
> I heard 2001::/64 and took them at their word. If 2001::/64 is a mistake
> and they're
> using something legitimate, then no problem. If I misheard, then also no
> problem.
>
> Either is possible.
>
> >
> > And, if what is said is really meaning 2001::/64 then I agree with you -
> > that's at IANA and one wouldn't juggle with 2001::/64 just like that.
> > If one wants to juggle with something then it's with fd00::/64
> > (ULA) and with 2001:db8::/32 (docu prefix).
>
> I have a problem with putting 2001:db8::/32 on actual hardware...
> I think that violates its intended purpose in the vast majority of
> cases, including this one.
>
> It shouldn't be too hard for Apple to come up with a /64 they can
> delegate to this safely.
>
> Beyond that, I still think that having it be user configurable is
> desirable for a wider range of testing scenarios to be supported.
>
> >
> >>>> *) Making IPv4 literals work on NAT64 networks when using
> >>>> high-level APIs Starting with this year's versions, if you use
> >>>> NSURLSession to connect to an IPv4 literal on an IPv6-only
> >>>> NAT64-DNS64 network, the API will bump in a IPv6 literal
> >>>> synthesized using RFC 7050. Note that this will not happen when
> >>>> using sockets directly. We do not support under-the-sockets
> >>>> bump-in-API (RFC 3338) and we do not support 464XLAT.
> >>
> >> They really should support 464XLAT at this point IMHO, though some of
> >> what they are doing may obviate or lessen the need. It will be
> >> interesting to see if this is sufficient for T-Mo to finally turn on
> >> IPv6 for my phone.
> >>
> >> Ideally, T-Mo should pull their head out [...] about dual-stack and
> >> Apple should pull their head out [...] about 464XLAT, but either one
> >> would meet my immediate needs.
> >
> > I wouldnt put it that blunt.  But I would agree that less transitioning
> > be faster transition.
>
> I've tried polite...
>  They haven't listened. Maybe if I'm blunt it will get their attention.
>
> If you have another alternative that might work, I'm open to it.
>
> >
> >> Unfortunately, they're both sitting there playing internet chicken
> >> waiting for the other one to blink.
> >>
> >> Given the number of other cellular networks that are following the
> >> same path as T-Mo, I think mass is on their side, but Apple may be
> >> too stubborn to blink and a head-on may be inevitable.
> >
> > I think I agree with you.  I am very happy one particular operator
> > leads with IPv6 deployment in a successful way.  But I am very unhappy
> > that operation is taken blindly as an example by other operators.  It has
> > drawbacks.
>
> Actually, T-Mo DOES NOT LEAD. Verizon led and was _WAY_ ahead of T-Mo and
> implemented dual-stack.
>
> Owen

464XLAT with DNS64 is a ABOMINATION.  The sooner it is removed the
better.  It only APPEARS to work well at the moment because there
is not a lot of validation happening in the application yet.  It
does not work with a validating recursive nameservers forwarding
queries to a DNS64 recursive server.

MAP and DS-Lite both do a better job and neither of them muck with
packet payload.  They also work with DNSSEC (464XLAT is usually
deployed with DNS64 and DNS64 DOES NOT WORK WITH DNSSEC (CD=1 does
NOT indicate validation is occuring despite what is written in RFC
6147, DO=1 is the ONLY indicatator that validation MAY be occuring.)).

All three have PMTU issues.

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