Subject: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 03 Jul 2017 17:41:10 +0200

Following my inputs to the update of HE, I’ve summited a new draft:

Reporting of Happy Eyeballs v2 Failures

I think this could be part of the main document, but just in case, to avoid missing the cut-off today …

Hopefully I can get a few minutes in the next meeting agenda to discuss about it, and as usual happy to get inputs, alternative suggestions, etc.

Note that even if the title mentions v2, I think it can work the same with the existing HE, but to me it makes sense to move on with the new version and include this reporting procedure.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 3 de julio de 2017, 17:36
Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
Asunto: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt

    A new version of I-D, draft-palet-ietf-v6ops-he-reporting-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-palet-ietf-v6ops-he-reporting
    Revision:	00
    Title:		Reporting of Happy Eyeballs v2 Failures
    Document date:	2017-07-03
    Group:		Individual Submission
    Pages:		4
    URL:            https://www.ietf.org/internet-drafts/draft-palet-ietf-v6ops-he-reporting-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-he-reporting/
    Htmlized:       https://tools.ietf.org/html/draft-palet-ietf-v6ops-he-reporting-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-ietf-v6ops-he-reporting-00

    Abstract:
       This document describes an extension to Happy Eyeballs in order to
       report IPv6 failures that force the fall-back to IPv4.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 20 Jul 2017 22:04:15 +1000

One thing I  forgot to ask at the mic: how does the host know that
syslog address (network prefix) changes/not valid anymore?
Does the discovery process happens every time the interface state
changes? Or....?

On Tue, Jul 4, 2017 at 1:41 AM, JORDI PALET MARTINEZ
<[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Jul 2017 14:16:26 +0200

Hi,

> Does the discovery process happens every time the interface state

We are turning in cycles.

Obviously DHCPv6 is not a good match if you run it in a volatile
environment, like "on an android phone used as a tethering CPE".  Nobody
is challenging that.

OTOH, in a fully managed environment, syslog hosts, network prefixes,
DNS recusors (<< the usual straw man) do not change "just so, and
by surprise" - this is known beforehand, planned, old and new system
exist in parallel (or old/new address, at least) and then you roll 
out the change to the clients.  Which totally voids that argument.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Jul 2017 12:17:31 +0000

Amen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 20 Jul 2017 14:18:20 +0200

The NSP prefix is something usually very stable in an operator network. Otherwise you have the same problem if the NSP used for the NAT64 if is changed quite often.

Anyway, we may specify some parameter such as lifetime, or something similar.

Actually, looking to 7.1.  IPv4 Address Literals from draft-ietf-v6ops-rfc6555bis, the problem is the same, I’m not sure if the authors have thought already about that issue?

Regards,
Jordi

---

From: David Schinazi <[email-masked]>
Date: Thu, 20 Jul 2017 14:38:20 +0200

The NAT64 prefix acquired using the technique described in RFC7050 is valid for as long as the DNS AAAA record for ipv4only.arpa.
Our implementation respects the DNS timeout and queries the network again if the prefix is needed after it has expired.

David

> On Jul 20, 2017, at 14:18, JORDI PALET MARTINEZ <[email-masked]> wrote:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 20 Jul 2017 14:41:29 +0200

Right, and very obvious, being a DNS mechanism, the solution is already there …

Thanks!

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]> en nombre de David Schinazi <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 20 de julio de 2017, 14:38
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-ietf-v6ops-he-reporting-00.txt

    David

---

From: Jen Linkova <[email-masked]>
Date: Thu, 20 Jul 2017 23:04:15 +1000

> environment, like "on an android phone used as a tethering CPE".  Nobody

Wait, what? Does Gmail (or some intermediate SMTP server) keep
corrupting my emails? It looks
like the text I sent is very different from the text you received....I
was talking about Jordi's proposal to use DNS to discover the syslog
server. Did you receive an email about DCHPv6? Or did my email ended
up in the wrong thread about another draft??
;)

> out the change to the clients.  Which totally voids that argument.

I was actually talking about the scenario when I have two ISP
connections at home. Or move from the corporate network to my home
one.