Subject: [v6ops] new draft: draft-byrne-v6ops-clatip

From: <[email-masked]>
Date: Fri, 11 Oct 2013 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-v6ops-clatip. Please take a look at it and comment.

---

From: <[email-masked]>
Date: Fri, 25 Oct 2013 15:04:09 +0200

Hi all,

I think this is a valueable draft, making sure that the CLAT IP address is well-defined and does not collide with other use cases when using RFC1918 addresses as the CLAT IP address.

Some thoughts:

- Can we exclude that a UE is using CLAT and DS-Lite at the same time?
- Should we also nail down a specific IP address out of that range (e.g. 192.0.0.3) for the CLAT interface with the freedom to choose a different IP address out of that subnet if necessary?
- Some application implementations switch to "I am behind NAT mode" when seeing an RFC1918 address and behave differently than directly connected to the Internet without NAT. This (in my opinion) bad "NAT discovery" will not be triggered with this IP address range.
- The requirements towards the CLAT IPv4 address should be better described. In the draft, I read "locally unique IPv4 address" and "unique address" - should be worded like "IPv4 address that must be unique within the UE and must not be used by any host the UE may connect to".

My €0.01,

Holger

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 31 Oct 2013 12:29:08 +0000

Cameron

As you asked for a quick review, here we go :-)

Getting a CLAT prefix from IANA sounds logical for me as we cannot 'steal' a prefix from someone else. This would also allow some IPv4-only application to detect CLAT (and possibly force the use of IPv6 even if happy eyeball is not happy).

My concern about re-using the DS-lite prefix is when (if ever) the CLAT will then go over DS-lite in some weird (home?) network configurations... This would confuse traceroute and possibly other ICMP mechanisms.

Sharing the DS-lite prefix also prevents a dual-stack measurement apps to detect whether it uses DS-lite or CLAT for the IPv4 path. About measurements, it is really easy to detect Teredo & 6to4 but much less 6RD (if you do not have the IPv4 address). So, 'just for measurements' I would love to have another prefix for CLAT

Hope this helps

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker (fred)
> Sent: vendredi 11 octobre 2013 14:45
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-byrne-v6ops-clatip
> 
> 
> A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-
> v6ops-clatip. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "cb.list6" <[email-masked]>
Date: Thu, 31 Oct 2013 07:04:20 -0700

Thanks Eric

On Oct 31, 2013 5:29 AM, "Eric Vyncke (evyncke)" <[email-masked]> wrote:
> Getting a CLAT prefix from IANA sounds logical for me as we cannot
'steal' a prefix from someone else. This would also allow some IPv4-only
application to detect CLAT (and possibly force the use of IPv6 even if
happy eyeball is not happy).

In theory, yes, but 464xlat is only a band-aid for the most archaic apps,
so I find it frustrating if someone tried to modify their app to have logic
to use or not use CLAT instead of enabling ipv6 or generically using HE.
Your line of thinking is correct in practice, I just dont like this certain
reality :)

In any event, the path in the i-d is to generalize the ds-lite range,  such
that in one step an app could know they are not on true dual-stack, they
are on some overlay.

> My concern about re-using the DS-lite prefix is when (if ever) the CLAT
will then go over DS-lite in some weird (home?) network configurations...
This would confuse traceroute and possibly other ICMP mechanisms.

The address is never on the wire from CLAT, and that topology should never
occur since both 464xlat emit only ipv6, so there should be no case where
the transition happens twice AND that on-path address responds...

But you made me think about the case of  tracerouting from 464xlat node to
a ds-lite node across the ipv6 internet... And  that b4 does not use the
specific addresses reserved for b4s.  In this case, the b4 can send a icmp
ttl exceeded to the clat, where the clat will see the packet with a
possible same source and destination

> Sharing the DS-lite prefix also prevents a dual-stack measurement apps to
detect whether it uses DS-lite or CLAT for the IPv4 path. About
measurements, it is really easy to detect Teredo & 6to4 but much less 6RD
(if you do not have the IPv4 address). So, 'just for measurements' I would
love to have another prefix for CLAT

Another  prefix dedicated for CLAT is an option.  Thanks for the feedback.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 31 Oct 2013 23:16:24 +0900

> possible same source and destination
But that can't happen, right? Nobody will ever see either the 464xlat IP
address or the DS-Lite IP address, because neither ever appears on the wire
- both terminals will see the public IPv4 address of the other side.

Even if they pass each other their IP addresses through some other
mechanism (e.g., SIP), that's no different from the case where two machines
talk to each other and both have the IPv4 address 192.168.1.2.

---

From: "cb.list6" <[email-masked]>
Date: Thu, 31 Oct 2013 07:28:53 -0700

On Oct 31, 2013 7:16 AM, "Lorenzo Colitti" <[email-masked]> wrote:
>> The address is never on the wire from CLAT, and that topology should
never occur since both 464xlat emit only ipv6, so there should be no case
where the transition happens twice AND that on-path address responds...
>>
>> But you made me think about the case of  tracerouting from 464xlat node
to a ds-lite node across the ipv6 internet... And  that b4 does not use the
specific addresses reserved for b4s.  In this case, the b4 can send a icmp
ttl exceeded to the clat, where the clat will see the packet with a
possible same source and destination

You are right.  In the case I was thinking of I overlooked that the aftr
would translate the ipv4 to public before returning towards the clat.

Furthermore, I doubt the range would be allowed to be translated to a
public ipv4 as a matter of policy on the aftr

CB