Subject: Re: [v6ops] <draft-ietf-v6ops-464xlat-optimization-00.txt> - pre-(shepherd-writeup) review

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 11 Jul 2020 11:23:05 +0200

Hi Jen,

I've tried to find information about:

1) DNSSEC support in CPEs.
2) DNSSEC support in CDNs.

It seems that neither of them is common.

In the case of the CDNs, it seems that the at least some of them, use dynamic mapping instead of anycast. This will mean that having DNSSEC signatures in advance to the server assigned to each "customer" will need to be done in real-time, which is too expensive. When anycast is used, then they can be pre-computed. 

I'm happy to hear otherwise from the WG.

So, if someone can provide some details of both aspects, we could consider it.

Regards,
Jordi
@jordipalet

El 10/7/20 13:30, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

    Hi Jen,

    El 10/7/20 9:53, "Jen Linkova" <[email-masked]> escribió:

        On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ
        <[email-masked]> wrote:
        > On this specific one, if the attacker spoof the DNS response, it will be able to create an invalid EAMT entry, so the client behind the NAT using that destination will not reach what it wanted to reach. This is not different if it happens without an EAMT.

        I believe it's different. The difference here is that invalid EAMT
        entry would affect *all* devices behind the CPE.
        Let's consider an example:
        - I have a CPE which has that optimization enabled. I have 5 devices
        at home, all of them are smart and using DNSSEC even.
        - Now one of them sent a A query for www.example.com.
        - The CPE sent an AAAA which got spoofed. The invalid EAMT entry is created.
        - Now none of the devices could reach www.example.com, despite the
        fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers.

    [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even the AAAA (without this optimization), the result is the same. In my opinion it all depends on how and "where" the attack occurs, because the DNS cache may be poisoned in the CPE or the hosts, etc. As said, I've no problem to mention it, but I think is not clear if it is worst or not, it very much depends on how and where the attach is performed.

        This is actually related to my point about 'when/how this feature gets
        enabled'.  It's not just must be explicitly enabled by an operator, it
        MUST be disabled if the roiter does not have IPv6 connectivity on the
        uplink (and the question is 'how to define that').

    [Jordi] This nullifies the full purpose of the optimization. The idea is that the optimization is performed as easy and automatically as possible if the WAN is IPv6-only. I will say in the other way around. If, in an extreme situation, an operator has any "big" trouble with this optimization, they will use TR-069 or whatever to disable it by default. Clearly the optimization will be only enabled by the CPE if it is using 464XLAT because it has IPv6-only WAN. I'm happy to add a sentence or even a section to clarify that, but for me an optimization for 464XLAT only works if 464XLAT is working, not otherwise!

        >
        > Having the same result as a regular DNS spoofing, should I mention it in the security considerations? May be indicating that it is the same kind of attack as a DNS spoofing without the EAMT entry, so it is not a new security risk.

        The impact is much higher as it would affect all devices, incl.ones
        which might not be even using that CPE as a resolver.
        Shall this feature only be used if the CPE is capable of DNSSEC?

    [Jordi] I don't see the relevance of DNSSEC in the CPE here. What I'm missing? I understand that if validation of DNSSEC is present and the RR have been spoofed then the CPE *already* will discard them, because it just discovered that the DNSSEC validation is failing. Right?

        We must be really careful here as what you are proposing basically
        nullifies Happy Eyeballs and might force content providers to go back
        to IPv4.

    [Jordi] In my experience, in an IPv6-only environment Happy Eyeballs doesn't "solve" most of the cases. Let's see:
    1) If the IPv6-only link or part of the IPv6-only network is broken inside the operator, IPv4 will not work as well. So, HE will only add delay in detecting the problem (the Resolution Delay).
    2) If the IPv6 connectivity is broken outside the operator network, in most of the cases, IPv4 may be broken as well.
    3) I agree that there may be cases where the IPv6 connectivity is broken outside the operator network and IPv4 is working, and a very typical example was when a www owner sets an AAAA record, not having IPv6 connectivity. This happen less and less often.

    **** However as explained in section 5.2.11, happy eyeballs it is only available in dual-stack hosts.

    A dual-stack hosts, normally, will not create the EAMT entry, neither use it (if it was created already by an IPv4-only host accessing the same FQDN).

    There may be an extreme case, where an IPv4-only hosts creates the EAMT entry, and then a dual-stack host, talking to the same destination, using HE, because suddenly the IPv6 connectivity fails, falls back to IPv4. In this case, the dual-stack host will be using the optimization. It may be in the case 1 or 2 above. HE with or without optimization is not resolving the problem.

    If we are in case 3 above, then is not a good thing that IPv4 is failing considering that we are in an IPv6-only operator?
    It is acceptable that dual-stack networks/services don't realize that IPv6 is not working?
    If there are IPv6-only hosts (example a NAT64+DNS64 instead of 464XLAT, in the same operator or others), they will not reach the destination, because HE will not help them, right?
    So, is this an acceptable trade-off?

        > I will try to respond to the other later on in the morning, and if needed update the last version with the relevant clarifications.

        Thank you!

        > El 10/7/20 9:04, "Jen Linkova" <[email-masked]> escribió:
        >
        >     Oh I forgot to add one more thing:
        >     - The Security Considerations section states that "This document does
        >     not have any new specific security considerations,
        >        besides the ones already known for DNS64.".
        >     I'm not sure it's the case. The proposed approach drastically
        >     amplifies DNS poisoning impact.
        >     If the attacker manages to spoof the DNS response the CPE would create
        >     an EAMT entry which would affect *all* traffic to that destination,
        >     even for devices/applications behind that CPE which might be using
        >     DNSSEC. This could create DoS attack vector and force CDN operators to
        >     turn off IPv6 for their caches.
        >     I believe that should be discussed in more detail.
        >
        >     On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova <[email-masked]> wrote:
        >     >
        >     > OK, I"ve read the document and before I finish the write up I'd like
        >     > to discuss a number of comments I have.
        >     > My apologies for not raising them during the WGLC - I was not paying
        >     > attention, got busy with work...
        >     >
        >     > 0) I might need coffee but I found the Abstract a bit confusing so if
        >     > I may suggest some text..
        >     >
        >     > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access
        >     > for IPv4-only devices or applications to IPv4-only or dual-stack
        >     > destinations over IPv6-only infrastructure. In that case the traffic
        >     > flows are translated twice: first from IPv4 to IPv6 (at the ingress
        >     > point to then IPv6-only network) and then from IPv6 back to IPv4 at
        >     > the egress point.  If the destination is IPv6-enabled that second
        >     > translation might not be required. This document describes some
        >     > optimization to 464XLAT and MAP-T deployments to avoid translating IP6
        >     > flows back to IPv4 if the destination is reachable over IPv6. The
        >     > proposed solution would significantly reduce the NAT64 utilisation in
        >     > the operator's network"
        >     >
        >     > 1) Introduction section
        >     > The draft says: "allow IPv4-only devices or applications to connect
        >     > with IPv4 services in Internet, by means of a
        >     >    stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described
        >     > by  [RFC7915]."
        >     >
        >     > Do you think it would help saying  "with IPv4 services in Internet
        >     > over IPv6-only infrastructure"?  Otherwise it sounds confusing - why
        >     > do we need anything at all to help IPv4-only clients to talk to
        >     > IPv6-only services?
        >     >
        >     > 2) ""This allows to translate the IPv6-only flow back to IPv4, in
        >     > order to forward it to Internet."
        >     >
        >     > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or
        >     > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used
        >     > extensively in the draft.
        >     >
        >     > 3) "In both cases (NAT46 and NAT64), the translation of the packet
        >     >    headers is done using the IP/ICMP translation algorithm defined in
        >     >    [RFC7915] and algorithmically translating the IPv4 addresses to IPv6
        >     >    addresses following [RFC6052]."
        >     >
        >     > IMHO this text would be more readable if we split it in two sentences:
        >     > " In both cases (NAT46 and NAT64), the translation of the packet
        >     >    headers is done using the IP/ICMP translation algorithm defined in
        >     >    [RFC7915] . Translation between IPv4 and IPv6 addresses is done as
        >     > per RFC6052]."
        >     >
        >     > 4) Section 3 is called "Possible Optimisation". However it comes
        >     > before the Section 4 (problem statement) and the text seems to be more
        >     > about the problem.
        >     > Also, the first 3 paragraphs of Section 4 (until "until "As shown in
        >     > the Figure 4" text) seem to repeat Section 3. Shall those two sections
        >     > be merged?
        >     > Or am I missing anything and they are actually talking about different things?
        >     >
        >     > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge
        >     > of the synthesis of AAAA records from the A records, so they can use
        >     >    a NAT64, without the need of doing a double-translation by means of
        >     >    the NAT46/CLAT." - who are "they"?  This is the first sentence of
        >     > the section so not sure who you are referring to.
        >     >
        >     > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'?
        >     >
        >     > 7) ""As it can be observed in the preceding picture, the situation is the
        >     >    same, regardless of in case of a wired network with a CE Router or a
        >     >    cellular network where a UE is connecting other devices (which may be
        >     >    IPv4-only or have IPv4-only apps), by means of a tethering
        >     >    functionality."
        >     >
        >     > IMHO it's a bit hard to parse...Maybe smth like:
        >     > "Examples of a topology shown on the picture above includes:
        >     > - a residential ISP IPv6-only access network with a dual-stack LAN
        >     > behind a CPE performing NAT46 (CLAT);
        >     > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only
        >     > applications running on that UE or for traffic originated by other
        >     > devices connected to the UE via tethering."
        >     >
        >     > 8) Section 5.1. Approach 1: DNS/Routing-based Solution
        >     > "5.1. Approach 1: DNS/Routing-based Solution
        >     > "Because the WKP is non-routable, this solution will only be possible
        >     >    if the CDN/cache is in the same ASN as the provider network, or
        >     >    somehow interconnected without routing thru" Internet."
        >     >
        >     > Maybe it's worth explicitly mentioning that this approach would
        >     > require that the path to the destination is NOT traversing NAT64
        >     > devices. Otherwise the simple configuration of such devices 'translate
        >     > everything with the destination address in the WKP' would become much
        >     > more complex.
        >     >
        >     > 9) Section 5.2.3
        >     > ""In normal conditions the TTL for both A and AAAA records, of a given
        >     > FQDN, should be the same,"
        >     >
        >     > I'm not sure it's the case actually and we can expect that to happen
        >     > 'normally'. Do you have any references proving that point?
        >     >
        >     > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs
        >     > Sorry but I have difficulties understanding those two sentences. What
        >     > 'existing procedures'  the resolver must be using?
        >     > IMHO this section would be much easier to understand if there is an
        >     > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries
        >     > would be created?
        >     > As most CDNs would have multiple entries, this is a key point of the proposal.
        >     >
        >     > 11) Section 5.2.8. Behavior in presence/absence of DNS64
        >     > "Furthermore,  because as indicated in Section 5.2.2, the EAMT entry
        >     > is not created
        >     >    when the service is IPv6-enabled."
        >     >
        >     > Is it correct? The section 5.2.2 seems to be talking about detecting
        >     > IPv6 enabled services and using their AAAAs for creating EAMT entries.
        >     >
        >     > 12)  (related to 11) The draft seems to assume that the CPE/UA knows
        >     > the NAT64 prefix somehow. As it's an operational document I believe it
        >     > would be beneficial to provide some guidance on how exactly the device
        >     > should discover the prefix. Obviously, the operator could use RFC8781
        >     > (PREF64 RA option) or PCE. Or the device and use RFC7050. However if
        >     > the device uses RFC7050 then the Section 5.2.8 shall discuss this.
        >     >
        >     > 13) IMHO sections 5.2.9.  Behavior when using literal addresses or non
        >     > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should
        >     > be follow each other or  sections 5.2.9. might have a reference to
        >     > 5.2.12.
        >     >
        >     > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs
        >     > IMHO, this section should make it explicit and very very clear: as
        >     > soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs
        >     > fallback to that IPv4 address becomes impossible. In case of
        >     > connectivity issues with the IPv6 address used in that EAMT entry, the
        >     > client would not be able to reach the destination.
        >     > I feel like the draft does not discuss the impact enough.  It's not
        >     > about delay, it's about IPv6 becoming the only protocol to reach
        >     > IPv6-enabled destinations for both dual-stack and IPv4-only hosts.
        >     > Maybe it's a good thing in 2020 ;)
        >     >
        >     > 15) Later in that section the draft says:
        >     > " So even if Happy Eyeballs is present, the fallback to IPv4-only
        >     > typically, will be slower than native IPv6 itself, because
        >     >    the added delay in the NAT46+NAT64 translations, when not using this
        >     >    optimization."
        >     >
        >     > I think it should be saying "IPv4 would be slower", not "fallback to
        >     > IPv4".  So maybe smth like " 'IPv4 is expected to be slower than
        >     > native IPv6 due to delays added by NAT46+NAT64. This optimization
        >     > reduced that delay by eliminating the need of the second translation
        >     > (NAT64)"?
        >     >
        >     > 16) The draft does not discuss the troubleshooting implication. For
        >     > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and
        >     > there is an EAMT entry for 8.8.8.8.
        >     > IMHO this draft needs to discuss this and potential impact on tech
        >     > support procedures.
        >     >
        >     > 17) Another thing which seems to be missing is some guidelines on
        >     > controlling this feature. I'd suggest adding some text about that.
        >     > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that
        >     > optimization disabled by default. The routers MUST have a knob to turn
        >     > it off if it's enabled.
        >     >
        >     > 18) Acknowledgements Section
        >     > Pls remove "....and TBD".
        >     >
        >     > --
        >     > SY, Jen Linkova aka Furry
        >
        >
        >
        >     --
        >     SY, Jen Linkova aka Furry
        >
        >
        >
        > **********************************************
        > IPv4 is over
        > Are you ready for the new Internet ?
        > http://www.theipv6company.com
        > The IPv6 Company
        >
        > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
        >
        >
        >

        -- 
        SY, Jen Linkova aka Furry

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

    This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Lencse Gábor <[email-masked]>
Date: Sat, 11 Jul 2020 11:44:32 +0200

Hi Jordi,

I have done a quick google search and found a 12 years old ICANN report 
with the following conclusion:

As a consequence, we conclude that just 6 units (25%) operate with full 
DNSSEC compatibility "out of the box." 9units (37%) can be reconfigured 
to bypass DNS proxy incompatibilities. Unfortunately, the rest (38%) 
lack reconfigurable DHCP DNS parameters, making it harder for LAN 
clients to bypass their interference with DNSSEC use.

Source: https://www.icann.org/en/system/files/files/sac-035-en.pdf

I hope that the situation has improved a lot since then.

I have also found 2 years old CZ.NIC presentation: 
https://static.ptbl.co/static/attachments/169316/1520904408.pdf

But I do not know, how representative it is.

Best regards,

Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 11 Jul 2020 15:46:42 +0200

Tks Gabor,

I already knew about the ICANN one.

I’m going to take a look to the other one, in case I need to change some wording in the document, the even if the CEs support DNSSEC the main issue is the CDNs.

Regards,

Jordi

@jordipalet

El 11/7/20 11:46, "v6ops en nombre de Lencse Gábor" <[email-masked] en nombre de [email-masked]> escribió:

Hi Jordi,

I have done a quick google search and found a 12 years old ICANN report with the following conclusion:

As a consequence, we conclude that just 6 units (25%) operate with full DNSSEC compatibility "out of the box." 9 units (37%) can be reconfigured to bypass DNS proxy incompatibilities. Unfortunately, the rest (38%) lack reconfigurable DHCP DNS parameters, making it harder for LAN clients to bypass their interference with DNSSEC use.

I have also found 2 years old CZ.NIC presentation: https://static.ptbl.co/static/attachments/169316/1520904408.pdf

Best regards,

Gábor

 

 

Regards,
Jordi
@jordipalet

 
    Hi Jen,

        On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ
        <[email-masked]> wrote:
        > On this specific one, if the attacker spoof the DNS response, it will be able to create an invalid EAMT entry, so the client behind the NAT using that destination will not reach what it wanted to reach. This is not different if it happens without an EAMT.

 

        >
        > Having the same result as a regular DNS spoofing, should I mention it in the security considerations? May be indicating that it is the same kind of attack as a DNS spoofing without the EAMT entry, so it is not a new security risk.

 

 

 
        > I will try to respond to the other later on in the morning, and if needed update the last version with the relevant clarifications.
 
        Thank you!
 
        > El 10/7/20 9:04, "Jen Linkova" <[email-masked]> escribió:
        >
        >     Oh I forgot to add one more thing:
        >     - The Security Considerations section states that "This document does
        >     not have any new specific security considerations,
        >        besides the ones already known for DNS64.".
        >     I'm not sure it's the case. The proposed approach drastically
        >     amplifies DNS poisoning impact.
        >     If the attacker manages to spoof the DNS response the CPE would create
        >     an EAMT entry which would affect *all* traffic to that destination,
        >     even for devices/applications behind that CPE which might be using
        >     DNSSEC. This could create DoS attack vector and force CDN operators to
        >     turn off IPv6 for their caches.
        >     I believe that should be discussed in more detail.
        >
        >     On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova <[email-masked]> wrote:
        >     >
        >     > OK, I"ve read the document and before I finish the write up I'd like
        >     > to discuss a number of comments I have.
        >     > My apologies for not raising them during the WGLC - I was not paying
        >     > attention, got busy with work...
        >     >
        >     > 0) I might need coffee but I found the Abstract a bit confusing so if
        >     > I may suggest some text..
        >     >
        >     > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access
        >     > for IPv4-only devices or applications to IPv4-only or dual-stack
        >     > destinations over IPv6-only infrastructure. In that case the traffic
        >     > flows are translated twice: first from IPv4 to IPv6 (at the ingress
        >     > point to then IPv6-only network) and then from IPv6 back to IPv4 at
        >     > the egress point.  If the destination is IPv6-enabled that second
        >     > translation might not be required. This document describes some
        >     > optimization to 464XLAT and MAP-T deployments to avoid translating IP6
        >     > flows back to IPv4 if the destination is reachable over IPv6. The
        >     > proposed solution would significantly reduce the NAT64 utilisation in
        >     > the operator's network"
        >     >
        >     > 1) Introduction section
        >     > The draft says: "allow IPv4-only devices or applications to connect
        >     > with IPv4 services in Internet, by means of a
        >     >    stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described
        >     > by  [RFC7915]."
        >     >
        >     > Do you think it would help saying  "with IPv4 services in Internet
        >     > over IPv6-only infrastructure"?  Otherwise it sounds confusing - why
        >     > do we need anything at all to help IPv4-only clients to talk to
        >     > IPv6-only services?
        >     >
        >     > 2) ""This allows to translate the IPv6-only flow back to IPv4, in
        >     > order to forward it to Internet."
        >     >
        >     > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or
        >     > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used
        >     > extensively in the draft.
        >     >
        >     > 3) "In both cases (NAT46 and NAT64), the translation of the packet
        >     >    headers is done using the IP/ICMP translation algorithm defined in
        >     >    [RFC7915] and algorithmically translating the IPv4 addresses to IPv6
        >     >    addresses following [RFC6052]."
        >     >
        >     > IMHO this text would be more readable if we split it in two sentences:
        >     > " In both cases (NAT46 and NAT64), the translation of the packet
        >     >    headers is done using the IP/ICMP translation algorithm defined in
        >     >    [RFC7915] . Translation between IPv4 and IPv6 addresses is done as
        >     > per RFC6052]."
        >     >
        >     > 4) Section 3 is called "Possible Optimisation". However it comes
        >     > before the Section 4 (problem statement) and the text seems to be more
        >     > about the problem.
        >     > Also, the first 3 paragraphs of Section 4 (until "until "As shown in
        >     > the Figure 4" text) seem to repeat Section 3. Shall those two sections
        >     > be merged?
        >     > Or am I missing anything and they are actually talking about different things?
        >     >
        >     > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge
        >     > of the synthesis of AAAA records from the A records, so they can use
        >     >    a NAT64, without the need of doing a double-translation by means of
        >     >    the NAT46/CLAT." - who are "they"?  This is the first sentence of
        >     > the section so not sure who you are referring to.
        >     >
        >     > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'?
        >     >
        >     > 7) ""As it can be observed in the preceding picture, the situation is the
        >     >    same, regardless of in case of a wired network with a CE Router or a
        >     >    cellular network where a UE is connecting other devices (which may be
        >     >    IPv4-only or have IPv4-only apps), by means of a tethering
        >     >    functionality."
        >     >
        >     > IMHO it's a bit hard to parse...Maybe smth like:
        >     > "Examples of a topology shown on the picture above includes:
        >     > - a residential ISP IPv6-only access network with a dual-stack LAN
        >     > behind a CPE performing NAT46 (CLAT);
        >     > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only
        >     > applications running on that UE or for traffic originated by other
        >     > devices connected to the UE via tethering."
        >     >
        >     > 8) Section 5.1. Approach 1: DNS/Routing-based Solution
        >     > "5.1. Approach 1: DNS/Routing-based Solution
        >     > "Because the WKP is non-routable, this solution will only be possible
        >     >    if the CDN/cache is in the same ASN as the provider network, or
        >     >    somehow interconnected without routing thru" Internet."
        >     >
        >     > Maybe it's worth explicitly mentioning that this approach would
        >     > require that the path to the destination is NOT traversing NAT64
        >     > devices. Otherwise the simple configuration of such devices 'translate
        >     > everything with the destination address in the WKP' would become much
        >     > more complex.
        >     >
        >     > 9) Section 5.2.3
        >     > ""In normal conditions the TTL for both A and AAAA records, of a given
        >     > FQDN, should be the same,"
        >     >
        >     > I'm not sure it's the case actually and we can expect that to happen
        >     > 'normally'. Do you have any references proving that point?
        >     >
        >     > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs
        >     > Sorry but I have difficulties understanding those two sentences. What
        >     > 'existing procedures'  the resolver must be using?
        >     > IMHO this section would be much easier to understand if there is an
        >     > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries
        >     > would be created?
        >     > As most CDNs would have multiple entries, this is a key point of the proposal.
        >     >
        >     > 11) Section 5.2.8. Behavior in presence/absence of DNS64
        >     > "Furthermore,  because as indicated in Section 5.2.2, the EAMT entry
        >     > is not created
        >     >    when the service is IPv6-enabled."
        >     >
        >     > Is it correct? The section 5.2.2 seems to be talking about detecting
        >     > IPv6 enabled services and using their AAAAs for creating EAMT entries.
        >     >
        >     > 12)  (related to 11) The draft seems to assume that the CPE/UA knows
        >     > the NAT64 prefix somehow. As it's an operational document I believe it
        >     > would be beneficial to provide some guidance on how exactly the device
        >     > should discover the prefix. Obviously, the operator could use RFC8781
        >     > (PREF64 RA option) or PCE. Or the device and use RFC7050. However if
        >     > the device uses RFC7050 then the Section 5.2.8 shall discuss this.
        >     >
        >     > 13) IMHO sections 5.2.9.  Behavior when using literal addresses or non
        >     > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should
        >     > be follow each other or  sections 5.2.9. might have a reference to
        >     > 5.2.12.
        >     >
        >     > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs
        >     > IMHO, this section should make it explicit and very very clear: as
        >     > soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs
        >     > fallback to that IPv4 address becomes impossible. In case of
        >     > connectivity issues with the IPv6 address used in that EAMT entry, the
        >     > client would not be able to reach the destination.
        >     > I feel like the draft does not discuss the impact enough.  It's not
        >     > about delay, it's about IPv6 becoming the only protocol to reach
        >     > IPv6-enabled destinations for both dual-stack and IPv4-only hosts.
        >     > Maybe it's a good thing in 2020 ;)
        >     >
        >     > 15) Later in that section the draft says:
        >     > " So even if Happy Eyeballs is present, the fallback to IPv4-only
        >     > typically, will be slower than native IPv6 itself, because
        >     >    the added delay in the NAT46+NAT64 translations, when not using this
        >     >    optimization."
        >     >
        >     > I think it should be saying "IPv4 would be slower", not "fallback to
        >     > IPv4".  So maybe smth like " 'IPv4 is expected to be slower than
        >     > native IPv6 due to delays added by NAT46+NAT64. This optimization
        >     > reduced that delay by eliminating the need of the second translation
        >     > (NAT64)"?
        >     >
        >     > 16) The draft does not discuss the troubleshooting implication. For
        >     > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and
        >     > there is an EAMT entry for 8.8.8.8.
        >     > IMHO this draft needs to discuss this and potential impact on tech
        >     > support procedures.
        >     >
        >     > 17) Another thing which seems to be missing is some guidelines on
        >     > controlling this feature. I'd suggest adding some text about that.
        >     > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that
        >     > optimization disabled by default. The routers MUST have a knob to turn
        >     > it off if it's enabled.
        >     >
        >     > 18) Acknowledgements Section
        >     > Pls remove "....and TBD".
        >     >
        >     > --
        >     > SY, Jen Linkova aka Furry
        >
        >
        >
        >     --
        >     SY, Jen Linkova aka Furry
        >
        >
        >
        > **********************************************
        > IPv4 is over
        > Are you ready for the new Internet ?
        > http://www.theipv6company.com
        > The IPv6 Company
        >
        > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
        >
        >
        >

 

 

 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops