Re: [sunset4] future of dnssec?

[Mark Andrews <[e-mail]>]

In message <[e-mail].C
O.UK>, "Heatley, Nick" writes:
> Some networks do not work successfully with the additional encapsulation.
> Mobile networks are the case in point.
> So the translation tech rightfully exists.

464XLAT is encapsulation with translation.  It drops the IPv4 path
MTU from 1500 to 1480.  DS-Lite drops the IPv4 MTU to 1460.  You
can't avoid the issue with tethered equipement.

For TCP connection initiatiate from the host you shouldn't be seeing
PMTU issues with either 464XLAT or DS-Lite as both should be
presenting iterface MTU that doesn't result in PTB's being generated
by the teco's equipement.  For 464XLAT the mss should be that of
IPv6.  For DS-Lite in the host mode the mss should be 20 bytes
smaller.

Or can't the phone manufactures actually do DS-Lite host mode
properly if they were to try?

Encapsulation in the connection initiating device is different to
encapsulation in the middle of the path.  You start out with a
smaller MTU.

Mark

> -----Original Message-----
> From: sunset4 mailto:[e-mail] On Behalf Of Mark Andrews
> Sent: 22 February 2017 21:03
> To: Marc Blanchet
> Cc: [e-mail]
> Subject: Re: sunset4 future of dnssec?
>
>
> In message <[e-mail]>, "Marc
> Blanchet"
> writes:
> > On 22 Feb 2017, at 9:36, Mark Andrews wrote:
> >
> > > In message <[e-mail]>, Ted
> > > Lemon
> > > writes:
> > >>
> > >> Nick, the solution to this is to do DNS64 in the validator.   If the
> > >> validator is a stub resolver, do the DNS64 hack there.   AFAIK the
> > >> technology to support this already exists.
> > >
> > > DNS64 really should just be made historic.  It does not work with
> > > DNSSEC.  There has NEVER been a NEED for NAT64 or DNS64.  They
> > > provides NO BENEFIT over other methods.  Every proported benefit
> > > turns out not to exist.
> > >
> > > Go do the comparitive analysis.
> >
> > I respectfully disagree. dual-stack incur many additional costs
> > operationally. deploying v6only infrastructure is more cost effective,
> > specially over the long run. nowadays, statistics show that a large
> > amount of trafic could be carried over IPv6, which means then that you
> > just need to care about the tail of the IPv4-only destinations,
> > which is where nat64/dns64 comes. But I guess you know all this.
>
> Stop with the knee jerk reactions.  What gave you the idea that I wasn't
> talking about IPv6-only networks?
>
> So use DS-LITE in HOST MODE.  The only DS with that is in the host which
> you cannot avoid if you are using IPv4 literals or is that too much dual
> stack.  A little bit inside the node with a fixed
> IPv4 address.  No routing.  No address assignments.
>
> As I said NAT64/DNS64 does not provide any benefits that are not
> available via other IPv4 as a service mechanisms with the added benefit
> that you don't have to teach applications / OS stack about
> DNS64 prefix discovery to deal with IPv6 literals.
>
> For NAT64/DNS64 and 464XLAT in the host *every* DNSSEC validator in the
> DNS path needs to be taught how to do DNS64 prefix discovery and therefor
> that it need to lie about AAAA results whether or not they are going to
> be used for a IPv6 connection or not.
>
> Mark
>
> > Marc.
> >
> > >
> > >>> On Feb 22, 2017, at 7:23 AM, Heatley, Nick <[e-mail]>
> > >> wrote:
> > >>>
> > >>> Post exhaustion, the majority of cellular networks and some public
> > >>> wifi
> > >> networks will use DNS64.
> > >>> DNSSEC and DNS64 do not get along. DNSSEC for A records only
> > >>> is
> > >> broken.
> > >>> Is this the reason why all content must go v6?
> > >>> Or is the case for DNSSEC still questionable?
> > >>> Or do end hosts need to perform DNS64 so DNSSEC for A records
> > >>> only
> > >> can be intact?
> > >>>
> > >>> NOTICE AND DISCLAIMER
> > >>> This email contains BT information, which may be privileged or
> > >> confidential. It's meant only for the individual(s) or entity named
> > >> above.
> > >>> If you're not the intended recipient, note that disclosing,
> > >>> copying,
> > >> distributing or using this information is prohibited.
> > >>> If you've received this email in error, please let me know
> > >>> immediately
> > >> on the email address above. Thank you.
> > >>>
> > >>> We monitor our email system, and may record your emails.
> > >>>
> > >>> EE Limited
> > >>> Registered office:Trident Place, Mosquito Way, Hatfield,
> > >>> Hertfordshire,
> > >> AL10 9BW
> > >>> Registered in England no: 02382161
> > >>>
> > >>> EE Limited is a wholly owned subsidiary of:
> > >>>
> > >>> British Telecommunications plc
> > >>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in
> > >>> England no: 1800000
> > >>>
> > >>> _______________________________________________
> > >>> sunset4 mailing list
> > >>> [e-mail] <mailto:[e-mail]>
> > >>> https://www.ietf.org/mailman/listinfo/sunset4
> > >> <https://www.ietf.org/mailman/listinfo/sunset4>
> > >
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: [phone]                 INTERNET: [e-mail]
> > >
> > > _______________________________________________
> > > sunset4 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sunset4
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>
>
> NOTICE AND DISCLAIMER
> This email contains BT information, which may be privileged or
> confidential. It's meant only for the individual(s) or entity named
> above.
> If you're not the intended recipient, note that disclosing, copying,
> distributing or using this information is prohibited.
> If you've received this email in error, please let me know immediately on
> the email address above. Thank you.
>
> We monitor our email system, and may record your emails.
>
> EE Limited
> Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire,
> AL10 9BW
> Registered in England no: 02382161
>
> EE Limited is a wholly owned subsidiary of:
>
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
> _______________________________________________
> sunset4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sunset4

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