Subject: [BEHAVE] Embedding vs obscuring IPv4 addresses

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2009 01:36:02 +0000

Various documents (including SIIT, and most of the individual drafts
submitted to Behave) propose constructing an IPv6 address by directly
embedding an IPv4 address somewhere in it.

In contrast, other documents (including STUNbis, and also Teredo which
embeds an IPv4 address in an IPv6 address) try to obscure the IPv4 address,
typically via XOR ffffffff so that when they are passed around in
application payloads that go through a NAT44 that tries to be "smart"
by modifying application payloads, that the payloads won't be modified.

Example Scenario:

  IPv6 ------- IPv6/IPv4 ------- "Helpful" -------- IPv4
  Host         Translator          NAT44            Host

Here, if an IPv4 address is embedded literally in a payload that
passes through the "helpful" NAT44, then it will be modified.
This may affect some applications/referral scenarios.

Of course applications may send legitimate data that happens
to match a 32-bit IPv4 address and such "helpful" NAT44s cause
data corruption and can break encrypted sessions (e.g., ssh) as a result.
Still, choosing a simple embedding scheme can cause problems.

On the other hand, an obscuring scheme (e.g. XOR ffffffff before
embedding) doesn't have those issues, which is why STUN and Teredo
obscure, but diagnosability is easier with embedding.  For example,
in the case a well-known prefix is used, the embedded address can be
shown in dotted-decimal (e.g., v4-mapped addresses do this) for
human readability.

Options:
a) Standardize only simple embedding
b) Standardize only obscuring
c) Standardize both for different scenarios

Thoughts?

-Dave

---

From: Rémi Després <[email-masked]>
Date: Wed, 10 Jun 2009 09:41:30 +0200

> c) Standardize both for different scenarios

Option c seems to be the only one that preserves compatibility with  
current specifications (obscure for STUN and Teredo; embed for 6to4,  
Isatap, 6rd, mapped addresses).
Where there is a new choice, embedding is IMHO preferable (simpler,  
easier maintenance, no interference between layers).

Regards,

RD

PS: Unfortunately, starting this morning and until June 26, I will  
hardly be able to process my e-mails.
If an answer is needed, it may therefore be after this date.
Thank you for your understanding.

>
> Thoughts?
>
> -Dave
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 Jun 2009 10:40:41 +0200

> c) Standardize both for different scenarios
thanks for the analysis, that was helpful (to me at least)
I would go for c) _but_ i wouldn't make a normative dependency on the 
obscuring approach.

I mean, as we agreed in the interim meeting (audioconf) we will have  
SIIT, DNS64 and NAT64 to have a default address transformation 
algorithm, which must be clearly separated from the rest of the 
specifications, so it can be changed easily.
the default algorithm should be the simple embedding, so we can move 
forward as fast as possible.
We should also standardize another transformation, the obscuring one, 
but neither the SIIT, DNS64 nor NAt64 should have a normative reference 
to that one.

Regards, marcelo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Jun 2009 07:32:36 -0400

> forward as fast as possible.

+1

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2009 15:00:24 +0000

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Wednesday, June 10, 2009 1:41 AM
> To: Dave Thaler
> Cc: Behave WG
> Subject: Re: [BEHAVE] Embedding vs obscuring IPv4 addresses
>
>
>
>
> Dave Thaler escribió:
> > Options:

You seem to be arguing for a variant of c which is standardize both
for different scenarios, but have a default that is scenario-independent
(as opposed to having the default be scenario-specific as c would
normally imply).  However, since telling a device what scenario it's
in could be manual configuration, you might be arguing that a device
should default to thinking it's in a particular scenario until manually
configured otherwise.  So I'm not sure which you meant.

In any case, I don't think it'd take any longer to say (for example)
embed the address XOR ffffffff than it would to say embed the literal
address, IF we agreed that the reasons to obscure outweigh the reasons
to embed literally.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2009 15:05:07 +0000

> From: Rémi Després [mailto:[email-masked]]
> Sent: Wednesday, June 10, 2009 12:42 AM
> To: Dave Thaler
> Cc: Behave WG

I'm not worried about compatibility with 6to4/ISATAP/6rd etc per se
since here we're defining addresses to be used with translators
not encapsulators.

-Dave

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 Jun 2009 06:44:24 -0700

> but neither the SIIT, DNS64 nor NAt64 should have a normative reference

So you prefer something easy to specify, even if it does not actually work?

-- Christian Huitema

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Jun 2009 13:52:39 -0400

>   Host         Translator          NAT44            Host

I'm sorry, I may be slow. I fail to see how the embedding of IPv4 addresses in
IPv6 addresses performed by the translator could be related in any way with the
"helpful" behaviour of the NAT44 device.

Or are we not talking about translation, but really about future application
protocols transporting IPv4 addresses in their payload?

Thanks,
Simon

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 Jun 2009 14:47:46 -0700

> protocols transporting IPv4 addresses in their payload?

As in, for example, tunnels.

-- Christian Huitema

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Jun 2009 19:35:48 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Wednesday, June 10, 2009 10:53 AM
> To: Dave Thaler
> Cc: Behave WG

Existing applications transporting IPv6 addresses in payloads
(and hence embedded IPv4 addresses in payloads that such NATs
modify).

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jun 2009 07:50:41 +0100

> (and hence embedded IPv4 addresses in payloads that such NATs

Can someone remind us of the prevalence of these broken NATs?

I'm very allergic to adding yet another horrible hack (and
shouldn't it be a configurable option if we must have it?).

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Jun 2009 15:29:43 +0200

On 11 jun 2009, at 8:50, Brian E Carpenter wrote:

>>> I'm sorry, I may be slow. I fail to see how the embedding of IPv4
>>> addresses in IPv6 addresses performed by the translator could be  
>>> related in any way with the "helpful" behaviour of the NAT44 device.
>>>

> shouldn't it be a configurable option if we must have it?).

Agree. It's not obvious that this is an issue in practice.

Two reasons why I prefer to have the IPv4 address in the bottom of the  
IPv6 address in "clear text":

- it's compatible with existing NAT-PTs

- it's compatible with existing dead::beef:12.34.56.78 address notation

So I would hesitate to obscure unless doing so has an obvious real- 
world benefit.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 Jun 2009 06:42:38 -0400

Dave Thaler escribió:
> normally imply).

I am not sure what scenarios do you have in mind. I mean, which 
scenarios do you think it would make sense to have the non obscuring by 
default and for which scenarios do you think it would make sense to have 
the obscuring by default?
>   However, since telling a device what scenario it's

I was not considering different scenarios in my first reply
> address, 
from my experience, everything takes more time :-)

> IF we agreed that the reasons to obscure outweigh the reasons
> to embed literally.
>   

i agree with this

Regards, marcelo

---

From: Xing Li <[email-masked]>
Date: Sat, 13 Jun 2009 15:02:18 +0800

> - it's compatible with existing NAT-PTs
and SIITs
> So I would hesitate to obscure unless doing so has an obvious 
> real-world benefit.
I agree. xing

---

From: Rémi Després <[email-masked]>
Date: Sat, 27 Jun 2009 12:11:50 +0200

> address, IF we agreed that the reasons to obscure outweigh the reasons

Pro embedding ( as  said in a previous e-mail):  simpler, easier  
maintenance, no interference between layers.

Pro obscuring: unclear to me in the case of NAPT64.
IMHO, more explanations would be needed before envisaging to specify  
an address-obscuring variant.
(And even more so, of course, before address obscuring could be  
envisaged as the only recommended choice) .

Regards,

RD