Hi,
As I already indicated several times, I think this is needed and agree with
this document. In fact, I've included a reference to this document in RFC8683.
Just a minor point regarding the abstract. I think it should be a single
paragraph, and moving most of the text to the intro (I've been
Hi all,
(dnsop copied because DNS64)
I'm working in a new version of this document.
Link to the document:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
It will be great if we can get some new inputs.
Thanks!
Regards,
Jordi
And this is what I tried to say several times:
We need to take advantage of HE and NHE, or other means, to "report" to the
ISPs about brokenness.
https://tools.ietf.org/html/draft-palet-v6ops-he-reporting-00
Regards,
Jordi
-Mensaje original-
De: v6ops en nombre de Tommy Pauly
Fe
Hi Barbara,
In my experience, there are two ways IPv6 can be broken:
1) ICMPv6 being filtered, so PMTUD doesn't work.
2) IPv6 deployment issues (including having records with no or bad IPv6
connectivity).
HE only helps for 2).
But 2 can be caused in different points between the source and
I'm with you, ideally they should use DHCPv6 ... so tell them :-)
Regards,
Jordi
-Mensaje original-
De: en nombre de Philip Homburg
Fecha: lunes, 9 de julio de 2018, 18:26
Para:
CC: JORDI PALET MARTINEZ
Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv
I agree that users changing DNS is a problem, but as said in my previous email
the alternative is forcing DHCPv6 (and an option for that) as a MUST for any
IPv6 implementation, or forcing a MUST for PCP support, so then RFC7225 can be
used.
I see both of those two options as a utopia right no
I think deprecating RFC7050 will be a bad idea, there are too many
implementations that really need that, while updating APIs/libraries to make
sure they comply with this seems easier.
For example, we could have a DHCPv6 option, but in the cellular world DHCPv6 is
not used ... and even in non
Hi Warren,
I agree this is needed, as RFC7050 is widely implemented, even in the case of
RFC8305 for allowing a somehow “equivalent” functionality as the CLAT for
literal addresses.
For the same reasons this document mention, in
draft-ietf-v6ops-nat64-deployment, I have:
The learn
Hi Philip,
Agree, ideally, should be a DHCPv6 bases mechanism as we already proposed long
time ago, because PCP is not present in many networks (unfortunately), while
DHCP is quite common.
We are happy to resurrect and review this work if needed:
https://tools.ietf.org/html/draft-li-intare
By the way, forgot to mention something else.
I’ve started also to work in a policy proposal for ICANN in order to make sure
that we get aligned.
Regards,
Jordi
-Mensaje original-
De: JORDI PALET MARTINEZ
Fecha: viernes, 24 de noviembre de 2017, 21:36
Para:
CC: , <6...@ietf.
Martinez , Jordi Martinez
Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt
has been successfully submitted by Jordi Palet Martinez and posted to the
IETF repository.
Name
11 matches
Mail list logo
