Re: ipv6 Digest, Vol 144, Issue 21

Thanks :)

On 9 April 2016 at 15:32, <ipv6-request@ietf.org> wrote:

> Send ipv6 mailing list submissions to
>         ipv6@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/ipv6
> or, via email, send a message with subject or body 'help' to
>         ipv6-request@ietf.org
>
> You can reach the person managing the list at
>         ipv6-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ipv6 digest..."
>
>
> Today's Topics:
>
>    1. Re: rfc2460bis question (otroan@employees.org)
>    2. RE: rfc2460bis question (Hemant Singh (shemant))
>    3. Re: DNS AAAA for free (Geordie Guy)
>    4. Re: DNS AAAA for free (Sander Steffann)
>    5. Re: DNS AAAA for free (Mark Smith)
>    6. Re: DNS AAAA for free (James R Cutler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Apr 2016 18:23:47 -0300
> From: otroan@employees.org
> To: 6man WG <ipv6@ietf.org>
> Cc: Bob Hinden <bob.hinden@gmail.com>
> Subject: Re: rfc2460bis question
> Message-ID: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org>
> Content-Type: text/plain; charset="us-ascii"
>
> Let me clarify what my position is, since there are some nuances here.
>
> While a discussion on header insertion may be necessary, it is not in
> context for taking RFC2460 to IS. If a proposal is made, then the working
> group should discuss that in the context of that proposal.
>
> The RFC2460 text has not caused interoperability issues. Which is why I'm
> not convinced this change was required.
>
> The default action, unless we can come to a different agreement, is to
> leave the RFC2460 text unchanged in RFC2460bis.
>
> Please do not view that as if I am condoning header insertion. That would
> have to be future work. RFC2460 is clear that routers should not look
> further into packets than the base IPv6 header.
>
> Best regards,
> Ole
>
>
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 842 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160408/883795f5/attachment.asc
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Apr 2016 21:34:41 +0000
> From: "Hemant Singh (shemant)" <shemant@cisco.com>
> To: "otroan@employees.org" <otroan@employees.org>, 6man WG
>         <ipv6@ietf.org>
> Cc: Bob Hinden <bob.hinden@gmail.com>
> Subject: RE: rfc2460bis question
> Message-ID: <952867b558d2498bb995480710f9302a@XCH-RTP-005.cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ole,
>
> Sounds reasonable to me - thanks.
>
> Hemant
>
> -----Original Message-----
> From: otroan@employees.org [mailto:otroan@employees.org]
> Sent: Friday, April 08, 2016 5:24 PM
> To: 6man WG
> Cc: Stefano Previdi (sprevidi); Bob Hinden; Hemant Singh (shemant)
> Subject: Re: rfc2460bis question
>
> Let me clarify what my position is, since there are some nuances here.
>
> While a discussion on header insertion may be necessary, it is not in
> context for taking RFC2460 to IS. If a proposal is made, then the working
> group should discuss that in the context of that proposal.
>
> The RFC2460 text has not caused interoperability issues. Which is why I'm
> not convinced this change was required.
>
> The default action, unless we can come to a different agreement, is to
> leave the RFC2460 text unchanged in RFC2460bis.
>
> Please do not view that as if I am condoning header insertion. That would
> have to be future work. RFC2460 is clear that routers should not look
> further into packets than the base IPv6 header.
>
> Best regards,
> Ole
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 9 Apr 2016 17:55:30 +1000
> From: Geordie Guy <geordie@gguy.me>
> To: otroan@employees.org
> Cc: v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
> Subject: Re: DNS AAAA for free
> Message-ID: <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me>
> Content-Type: text/plain;       charset=us-ascii
>
> This is genuinely awesome.
>
> Geordie
>
> Sent from my mobile. Please excuse any unusual brevity or typos while I'm
> on the go.
>
> > On 8 Apr 2016, at 9:27 PM, otroan@employees.org wrote:
> >
> > Here is an interesting draft being presented in dnsop today.
> >
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1
> >
> > The proposal is to allow AAAA records in response to A queries.
> >
> > Best regards,
> > Ole
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 9 Apr 2016 12:55:05 +0200
> From: Sander Steffann <sander@steffann.nl>
> To: otroan@employees.org
> Cc: v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
> Subject: Re: DNS AAAA for free
> Message-ID: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> > On 08 Apr 2016, at 13:27, otroan@employees.org wrote:
> >
> > Here is an interesting draft being presented in dnsop today.
> >
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1
> >
> > The proposal is to allow AAAA records in response to A queries.
>
> One question: if clients send requests for both A and AAAA records
> simultaneously, how will including the AAAA answer in the A request help?
> The client will just get the AAAA answer twice: once on the A request and
> once on the AAAA request. If lookups were serialised and the A
> request/response was completed before starting the AAAA request it would
> make the second request unnecessary, but that's not what I see in
> practice...
>
> It looks like good intentions, I'm just trying to figure out how this
> would work in practice :)
>
> Cheers!
> Sander
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 455 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/ebc82e8f/attachment.asc
> >
>
> ------------------------------
>
> Message: 5
> Date: Sat, 9 Apr 2016 23:11:11 +1000
> From: Mark Smith <markzzzsmith@gmail.com>
> To: Sander Steffann <sander@steffann.nl>
> Cc: 6man WG <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
> Subject: Re: DNS AAAA for free
> Message-ID:
>         <CAO42Z2wcCNXtOPDNGT8pYL=adMyaj3qu4ZY=
> rUmGWMWCtWRgXg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 9 Apr 2016 8:55 PM, "Sander Steffann" <sander@steffann.nl> wrote:
> >
> > Hi,
> >
> > > On 08 Apr 2016, at 13:27, otroan@employees.org wrote:
> > >
> > > Here is an interesting draft being presented in dnsop today.
> > >
>
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1
> > >
> > > The proposal is to allow AAAA records in response to A queries.
> >
> > One question: if clients send requests for both A and AAAA records
> simultaneously, how will including the AAAA answer in the A request help?
> The client will just get the AAAA answer twice: once on the A request and
> once on the AAAA request. If lookups were serialised and the A
> request/response was completed before starting the AAAA request it would
> make the second request unnecessary, but that's not what I see in
> practice...
> >
> > It looks like good intentions, I'm just trying to figure out how this
> would work in practice :)
> >
>
> Having briefly looked at it, it seems there is an efficiency benefit.
> However, answering an A query with both an A and AAAA response might
> incentivise just sending A queries.
>
> Perhaps the opposite would be better - sending an AAAA query would result
> in an AAAA and A answer. That might create a small and subtle incentive to
> use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures.
>
> Regards,
> Mark.
>
> > Cheers!
> > Sander
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/03f3b360/attachment.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Sat, 9 Apr 2016 10:32:38 -0400
> From: James R Cutler <james.cutler@consultant.com>
> To: otroan@employees.org
> Cc: v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
> Subject: Re: DNS AAAA for free
> Message-ID: <CFE92148-462D-497A-B633-534AA3CB0ACB@consultant.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On 08 Apr 2016, at 13:27, otroan@employees.org <mailto:
> otroan@employees.org> wrote:
> >
> > Here is an interesting draft being presented in dnsop today.
> >
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1
> <
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1
> >
> >
> > The proposal is to allow AAAA records in response to A queries.
>
> In most conversations it is considered polite to answer the question asked
> and not to provide confusing extra data. This proposal violates that.
>
> James R. Cutler
> James.cutler@consultant.com
> PGP keys at http://pgp.mit.edu
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/c4aad4e5/attachment.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 872 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/c4aad4e5/attachment.asc
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ipv6 mailing list
> ipv6@ietf.org
> https://www.ietf.org/mailman/listinfo/ipv6
>
>
> ------------------------------
>
> End of ipv6 Digest, Vol 144, Issue 21
> *************************************
>