Subject: [nat66] I'd appreciate comments

From: Fred Baker <[email-masked]>
Date: Mon, 6 Dec 2010 11:03:21 -0800

I posted
    ftp://ftpeng.cisco.com/fred/nat66/draft-mrw-nat66-00-01-diff.html
    ftp://ftpeng.cisco.com/fred/nat66/draft-mrw-nat66-01.html
to Margaret for comment. She might tell me to scrap it - it's a big change from draft-mrw-nat66-00. However, I'd appreciate comments on it from this list.

The big changes are:
   - Change the acronym "NAT66" to "NPTv6", so people don't read
     "NAT" and MEGO.
   - Change the term used to refer to the function from "NAT66
     device" to "NPTv6 Translator". It's not a "device" function,
     it's a function that is applied between two interfaces. Consider
     a router with two upstreams and two legs in the local network;
     it will not translate between the local legs, but will translate
     to and from each upstream, and be configured differently for
     each of the two ISPs.
   - Comment specifically on the security aspects.
   - Comment specifically on the application issues raised on this
     list.
   - Comment specifically on multihoming, load-sharing, and asymmetric
     routing.
   - Spell out the hairpinning requirement and its implications.
   - Spell out the service provider side of Address Independence;
     -00 focuses on the edge's view
   - Detail the algorithm in a manner clearer to the implementor
     (I think)
   - Spell out the case for GSE-style DMZs between the edge and the
     transit network, which is about the implications for the global
     routing table.
   - Refer to draft-ietf-v6ops-cpe-simple-security

---

From: jefsey <[email-masked]>
Date: Tue, 07 Dec 2010 00:53:02 +0100

At 20:03 06/12/2010, Fred Baker wrote:
>to Margaret for comment. She might tell me to scrap it - it's a big 
>change from draft-mrw-nat66-00. However, I'd appreciate comments on 
>it from this list.

Fred,
we certainly carefully review this. This seems to be what we call for 
for years and documented for an ITU /3 block in 2005. This way the 
local part of the address we call IDv6 is uncoupled from IPv6 by a 
function. This brings stability to both side and certainly go with 
the IUI (Intelligent/Internet Use Interface) concept derived from 
IDNA2008 consensus.
Thanks
jfc

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

---

From: JFC Morfin <[email-masked]>
Date: Wed, 08 Dec 2010 22:43:58 +0100

>change from draft-mrw-nat66-00. However, I'd appreciate comments on 

Dear IUsers,

Fred Baker has issued a I_D which seems to go in our IDv6 way. I 
ported it under a wiki page at http://iucg.org/wiki/WIKI_NPTv6_Draft_-_Baker.
I also wikified at http://iucg.org/wiki/WIKI_DRAFT_GSE_for_IPv6 an 
1997 I_D he refers to in an important appendix.

This seems a proposition that could fit the IUI concept, so I suggest 
that we discuss it on the list, or through private/contrib if you 
want to stay in public domain.

jfc

PS. Fred, I noted the following typos:

3.1.
When an NPTv6 Translator is configured, the translation function 
first ensures that the internal and external prefix[es] are the same length

4.1.  Prefix Configuration and generation
and SHOULD store the randomly generated prefix [in] non-volatile 
storage for continued use.

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Dec 2010 14:52:21 -0800

Let me know, unicast, if I can help. You will find a need to track the draft as it progresses, as it is not in final form until it's an RFC.

I think the acronyms you're looking for are all specified in the draft. For example, the GSE draft, as noted in the spec, is a reference to a particular draft, and a ULA is specified in RFC 4193. Are there any in particular that I have not given the reference for?

Is there a specification, in English, of what you want in your IDv6 or "iUsers kind of way"? Given questions, the IETF is here to provide answers... I have poked around on the IUCG wiki, but to be honest I don't see much there to respond to.

The adjustment:

We are keeping the TCP and UDP checksums intact between the inside and the outside networks; these include a "pseudoheader" which is a subset of the IP header, so a change to those parts of the IP header has to change the checksum. To do so, we either have to update them in the TCP or UDP headers, which means that we can't encrypt data (IPsec) or that the router has to parse through all of the IPv6 sub-headers to find the transport header. We update the checksum calculation in the IP address in order to avoid those issues.

If you will, this is an addition problem. we could calculate the new checksum by saying

     consider the addreses to each be arrays of 16 bit numbers:
     struct ipv6header {
            ...
            unsigned short destination[8], source[8];
     } *p;

we could calculate the new value as

      p->source[3] += (inside[0]+inside[1]+inside[2]) - (outside[0]+outside[1]+outside[2])

(which I might have backwards) and assuming + and - are on's complement arithmetic. Being computer nerds, we note that "inside" and "outside" are constants within the configuration, and therefore that long calculation is a constant within the configuration. So we calculate it once. In the draft, I called the the "adjustment".

On Dec 8, 2010, at 2:24 PM, Marie-France Berny wrote:

> Jefsey! 
> 
> its a long time!
> 
> I saw your work on the site and printed these papers this after-noon. At first reading (and I forgot a few things we discussed nearly a year ago), it seems that it is not that bad. This seems to explain in their IETF own way some of the thing we want in our IUsers way.  What we would need is to take all their phrases - including ULA, and GSE draft, etc. and turn them into a user document we can understand (I will not carry that work!)  and check if this is what we want or not.
> 
> I am probably a lot stupid as usual at first glance. But I did not grasp the purpose of the "adjustment".  
> 
> Marie-France Berny
> 
> 2010/12/8 JFC Morfin <[email-masked]>
> Fred Baker has issued a I_D which seems to go in our IDv6 way. I ported it under a wiki page at http://iucg.org/wiki/WIKI_NPTv6_Draft_-_Baker.
> I also wikified at http://iucg.org/wiki/WIKI_DRAFT_GSE_for_IPv6 an 1997 I_D he refers to in an important appendix.
> 
> This seems a proposition that could fit the IUI concept, so I suggest that we discuss it on the list, or through private/contrib if you want to stay in public domain.
> 
> jfc
> 
> 
> When an NPTv6 Translator is configured, the translation function first ensures that the internal and external prefix[es] are the same length
> 
> and SHOULD store the randomly generated prefix [in] non-volatile storage for continued use.
> 
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iucg
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Dec 2010 17:15:04 +0100

Le 6 déc. 2010 à 20:03, Fred Baker a écrit :
> ... I'd appreciate comments on it from this list.

1.
In a mail of Oct. 31 to yourself with copies to Margaret and to the list, I wrote:
<<<
Your draft-mrw-nat66-00 says:
(a) "If the resulting value is 0xFFFF, it is changed to 0x0000" (sec. 8, second paragraph)
...
I found in the draft no technical justification for these rules, so that:
- The reason for (a) remains obscure to me.  
... until you would provide TECHNICAL REASONS showing how (a) ..., or some revised rules, would ensure address-mapping reversibility, it is legitimate to doubt, as I do, that your new proposal works in all identified cases. 
I didn't receive any answer yet, and the new draft hasn't changed on this point. 

2.
Here is, then, a further explanation on the problem I see:
- If a translation includes a last step that forces a single final result for two different intermediate results, *it cannot be reversible*.
- Sec. 8 says "If the resulting value is 0xFFFF, it is changed to 0x0000", this applying to both translation directions as confirmed in the example.
- Thus, two different original values of the 16-bit modified 16-bit word can, in the outgoing translation, give the same final value 0x0000. There is then no way in the reverse direction to determine which was the original value. 

3.
For /48 prefixes, *the problem can easily be fixed*.
It is sufficient to delete the change from 0xFFFF to 0x0000 in the outgoing translation.

(Concerning the incoming translation, an example should show why this change is actually needed. If it wouldn't, discarding packets addressed to the forbidden 0xFFFF subnet would be better than sending them to the 0x0000 subnet. The example would show that the specified algorithm can translate an original 0x0000 into a value that, when translated back, gives 0xFFFF.)  

4.
For longer prefixes, I found *NO SIMPLE SOLUTION*.
If there is enough pressure to get a solution also for this case, a convincing proof that the proposed solution works should IMHO be provided. 

5.
I have many other comments, but this one is the important enough to deserve an independent answer.

Regards,
RD

---

From: Marie-France Berny <[email-masked]>
Date: Wed, 8 Dec 2010 23:24:17 +0100

Jefsey!

its a long time!

I saw your work on the site and printed these papers this after-noon. At
first reading (and I forgot a few things we discussed nearly a year ago), it
seems that it is not that bad. This seems to explain in their IETF own way
some of the thing we want in our IUsers way.  What we would need is to take
all their phrases - including ULA, and GSE draft, etc. and turn them into a
user document we can understand (I will not carry that work!)  and check if
this is what we want or not.

I am probably a lot stupid as usual at first glance. But I did not grasp the
purpose of the "adjustment".

Marie-France Berny

>> to Margaret for comment. She might tell me to scrap it - it's a big change
>> from draft-mrw-nat66-00. However, I'd appreciate comments on it from this
>> list.
>>
>
> Dear IUsers,
>
> Fred Baker has issued a I_D which seems to go in our IDv6 way. I ported it
> under a wiki page at http://iucg.org/wiki/WIKI_NPTv6_Draft_-_Baker.
> I also wikified at http://iucg.org/wiki/WIKI_DRAFT_GSE_for_IPv6 an 1997
> I_D he refers to in an important appendix.
>
> This seems a proposition that could fit the IUI concept, so I suggest that
> we discuss it on the list, or through private/contrib if you want to stay in
> public domain.
>
> jfc
>
>
> When an NPTv6 Translator is configured, the translation function first
> ensures that the internal and external prefix[es] are the same length
>

---

From: JFC Morfin <[email-masked]>
Date: Thu, 09 Dec 2010 20:35:29 +0100

Hi Fred,

Let me address this.

A few French people gathered around me over the last two years as 
they wanted to see how we could technically protect the Project.FRA 
of a francophone TLD, and other linguistic and culturally related 
TLDs; and thereby to find a way to technically obtain an Internet 
that would be "people oriented, caractère humain, centrada en la 
persona", which is exactly what the WSIS unanimously declared that 
the information society had to be. This meant a clear border in the 
same technology (RFC 1958) between what was simplified (RFC 3439) by 
the engineers, and what was individually decided by the people's diversity.

This has led to the IDNA2008 consensus and RFC set. The solution was 
qualified as "unusual" in RFC 5895. This is because we identified 
(and this is why I could join the consensus) and illustrated that a 
part of the people's peer to peer relation had to be intelligently 
supported at the fringes, i.e. outside the end to end connection: off 
the wire/rope. In the IDNA2008 case, it is the UTF-8 entry that is to 
be translated into ASCII and we identified that there could be an 
unlimited number of ways of doing it, depending on the language, 
script, and context. In other areas this can be the addresses, the 
referentials, the meanings, the economic nature of the relation, the 
network time, the content, etc.

"unusual" meant that things are to be coordinated after the socket, 
outside of the Internet, at the users' machines. This meant there is 
a network side and a network use side. In the case of IDNA, we also 
identified that the network use side is not the user's side. Hence, 
the need/existence of an Internet Use Interface (IUI) middle-capacity 
to be explored, documented, and experimented.

1.  The first question was, therefore, where was it best to document 
such an IUI?

2.  The second question was that the division between the internal, 
peripheral, and external internets permitting a multiplication of 
additions/changes/extensions to the way we currently use the Internet 
without changing a single bit to the internal internet, how to best 
manage the transition towards what was, therefore, only a different 
reading context of the same RFCs?

3.  The third issue was that the decoupling of the external user's 
from the network technology by a smart IUI permitting  the 
consideration of a user centric capability to simultaneously use any 
alternative technology, internet evolution, new generation 
architecture, new addressing plan, new name spaces, etc.

Point (1) was addressed by my appeal to the IESG and IAB for not 
warning the community about the fundamental change in the reading of 
the Internet architecture IDNA2008 introduced and illustrated. The 
target was to quickly make sure that the IETF was or was not the 
proper place to document the IUI. The responses showed that the IETF 
felt concerned by the implication but did not want to be the 
designated IUI place.

Point (2)'s main immediate extension is the ML-DNS (i.e. a multilayer 
DNS, through an intelligent front-end for a strictly respected DNS). 
I announced it three years ago as a future continuation of IDNA2008 
once it would be settled. I am a few months late, but its principle 
has been experimented for a long time and I should be able to release 
an experimental prototype soon. This will be an "interbox" user 
(Linux/Windows) software including its own DNS server and a 
functional CLASSES/actions dispatcher. This opens up a very large 
number of possibilities including an unlimited virtual root, classes, 
and presentations, the full use of naming (identification, 
declaration, denomination), support of an interapplication system, 
etc. and the IDv6 support (see below). Unfortunately ICANN chose to ignore it.

Point (3) actually identifies the emergence of a new community, the 
Intelligent Users community, we abbreviate this as IUsers (also good 
for what I and others are: lead users) or the "IUse" community. It 
corresponds to the first layers that we added to OSI 
(interapplications, pseudo-network applications, and in the Internet 
case, presentation), towards the Intersem architecture (i.e. the 
Internet of thoughts) that needs them. The Intersem must be 
considered as an intricate network of person's systems, we call them 
cybships, in technical symbiosis but culturally empowered if we do 
not want everyone think "google".

In terms of internal addressing, the needs and possibilities that we 
have are large because we want to be able to support a large number 
of "plug-and-play" applications and a broad number of different 
classifications. This means that IPv6 IIDs are the best 
practical/available choice. Since we can use them anywhere to connect 
anything, we use the word IDv6 to designate them even outside of the 
IPv6 environment. We use "GRIDv6" (Global Region IDv6) for 
specialized addressing plans that people can use, for example for 
linguistic address translation functions (giving each concept/notion 
an address that we might use for semantic addressing), etc.

We consider domain name labels as alphadigital (0-Z) numbers with the 
"-" as a sub-label separator. This means that we can easily 
conceptually handle IDv6 as 1 to 13 alphadigital long domain name 
labels (one or several labels separated by a dot [two more than a DOS 
file names, e.g.: an.ipv6.address.jefsey.com]).

This is why your NPTv6 seems to be a good solution for us. With a 
long IETF background. It could also be quickly implemented in the 
Interbox testing project. I discussed something similar with Houlin 
Zao in 2005 for an ITU/3 block, differentiating the routing part from 
the local addressing part. Moreover, we could then use  LISP like 
sub-sub-addresses for deeper local (host) addressing.

At 23:52 08/12/2010, Fred Baker wrote:
>Let me know, unicast, if I can help. You will find a need to track 
>the draft as it progresses, as it is not in final form until it's an RFC.
>
>I think the acronyms you're looking for are all specified in the 
>draft. For example, the GSE draft, as noted in the spec, is a 
>reference to a particular draft, and a ULA is specified in RFC 4193. 
>Are there any in particular that I have not given the reference for?

No, thank you it is OK. Marie-France's remark was a good one. She 
would like me to present them NPTv6 as a compact IUser oriented with 
all the relevant issues introduced in the same document. The IUCG is 
meant to interface the IETF and Lead Users (people who are ready to 
modify their internet for it to suit their needs and who are not used 
to standardization, nor have time for participating). If I can 
transform your RFC in an IUse Best Practice equivalent, it means both 
sides of the IUI are in tune.

The ULA concept seems acceptable, but there is a risk of conflict and 
complexity?  At our level we thought of a default local prefix, since 
GRIDv6 would already be used.

>Is there a specification, in English, of what you want in your IDv6 
>or "iUsers kind of way"? Given questions, the IETF is here to 
>provide answers... I have poked around on the IUCG wiki, but to be 
>honest I don't see much there to respond to.

No. All of this is emerging right now, after the response of the IAB 
and IESG, and the IAB road map, we want to carefully consider it all. 
This is really a bootstrap period. We started preparing with some 
IUCG pages on the Inteplus, but since this is to be multitechnology, 
a public domain stream looks more appropriate.

Actually my plan, now that we have clearly identified the principle 
and the first priorities, is to explore in testing and to discover 
what is possible with a few real life projects such as "Projet.FRA" 
(a francophone open ontology TLD using its namespace as a taxonomy), 
and "Multilinc" (multiple linguistic TLDs, to explore 
multilingualization, i.e. languages working together at the common 
tools level) and may be "PERFIDA" (a private use RFID oriented space).

>The adjustment:
>
>We are keeping the TCP and UDP checksums intact between the inside 
>and the outside networks; these include a "pseudoheader" which is a 
>subset of the IP header, so a change to those parts of the IP header 
>has to change the checksum. To do so, we either have to update them 
>in the TCP or UDP headers, which means that we can't encrypt data 
>(IPsec) or that the router has to parse through all of the IPv6 
>sub-headers to find the transport header. We update the checksum 
>calculation in the IP address in order to avoid those issues.

Yes. This is a smart idea! (But we have not the expertise of Rémi 
Desprès to analyse it and question some details).

Too bad it makes us lose two bytes in the address (unless IPSec is 
carried in the IUI - after the NPTv6 process?). We would need to 
indicate somewhere that we could use an extended IPv6 header. We have 
needs for that, but it is too early to discuss this. Our priorities 
are to test the InterPlus concept (Plugged Layers on the User Side) 
with the ML-DNS and internal IDv6 ported by 3rd or 4th level domain names.

GSE
I understand that an edge network may have several upstreams that it 
can use to send (and rotate upstreams) but also that on each of these 
upstreams it has a different address.

jfc

---

From: Marie-France Berny <[email-masked]>
Date: Thu, 9 Dec 2010 22:42:40 +0100

I may be wrong but I understand that IPsec can be at least used with IPv4
and IPv6. So the best solution seems to be to add IPsec as a frontend to the
NPTv6 function of for IPv4. In this case the full subnet two bytes are
available to the user. However, there is need for one bit to tell if an
adjustment was made or not.
MFB

2010/12/9 JFC Morfin <[email-masked]>

>  Too bad it makes us lose two bytes in the address (unless IPSec is carried
> in the IUI - after the NPTv6 process?). We would need to indicate somewhere
> that we could use an extended IPv6 header. We have needs for that, but it is
> too early to discuss this. Our priorities are to test the InterPlus concept
> (Plugged Layers on the User Side) with the ML-DNS and internal IDv6 ported
> by 3rd or 4th level domain names.
>
> *GSE
> *I understand that an edge network may have several upstreams that it can
> use to send (and rotate upstreams) but also that on each of these upstreams
> it has a different address.
>
> jfc
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Dec 2010 13:47:23 -0800

On Dec 9, 2010, at 1:42 PM, Marie-France Berny wrote:

> I may be wrong but I understand that IPsec can be at least used with IPv4 and IPv6. So the best solution seems to be to add IPsec as a frontend to the NPTv6 function of for IPv4. In this case the full subnet two bytes are available to the user. However, there is need for one bit to tell if an adjustment was made or not.

I'm in favor of IPsec; ESP (Encryption or the ESP-NULL integrity check) works through this. AH doesn't. 

I'm not at all sure how that relates to the subnet part. If the ISP gives you an N bit prefix, you have 64-N bits available for the subnet.

> Too bad it makes us lose two bytes in the address (unless IPSec is carried in the IUI - after the NPTv6 process?). We would need to indicate somewhere that we could use an extended IPv6 header. We have needs for that, but it is too early to discuss this. Our priorities are to test the InterPlus concept (Plugged Layers on the User Side) with the ML-DNS and internal IDv6 ported by 3rd or 4th level domain names.
> 
> GSE
> I understand that an edge network may have several upstreams that it can use to send (and rotate upstreams) but also that on each of these upstreams it has a different address.
> 
> jfc
>

---

From: jefsey <[email-masked]>
Date: Thu, 09 Dec 2010 23:27:51 +0100

At 22:42 09/12/2010, Marie-France Berny wrote:
>I may be wrong but I understand that IPsec can be at least used with 
>IPv4 and IPv6. So the best solution seems to be to add IPsec as a 
>frontend to the NPTv6 function of for IPv4. In this case the full 
>subnet two bytes are available to the user. However, there is need 
>for one bit to tell if an adjustment was made or not.
>MFB

Marie-France,

As Fred says you get a 64-N space, N being what the ISP gives you. 
The real issue you raise is what we called IPP, i.e. a way to let 
know that an adapted/extended IP header is  being used. Here Fred discusses :

- an ISP based routing prefix which is independent from the IDv6 
local prefix (we use 64 bits for local addressing, but we need 128 
bits addresses if is IPv6 is used internally - he is using the 
ULA  proposition)
- a transparency to IPsec in using two bytes.

Our interest may not be directly in what he proposes - this is what 
we need to understand. But our interest seems at least to be in the 
homogeneity permitted this way between a large edge networks solution 
and our own *possible* solution for lead users' systems.

jfc

>2010/12/9 JFC Morfin <<mailto:[email-masked]>[email-masked]>
>indicate somewhere that we could use an extended IPv6 header. We 
>have needs for that, but it is too early to discuss this. Our 
>priorities are to test the InterPlus concept (Plugged Layers on the 
>User Side) with the ML-DNS and internal IDv6 ported by 3rd or 4th 
>level domain names.
>
>GSE
>can use to send (and rotate upstreams) but also that on each of 
>these upstreams it has a different address.
>
>jfc
>
>

---

From: "S.P.Zeidler" <[email-masked]>
Date: Tue, 14 Dec 2010 00:05:56 +0100

Hi,

> I found in the draft no technical justification for these rules, so that:

In one's complement arithmetic, 0xFFFF and 0x0000 are indistinguishable
variants of zero. Since they happen to not be the same in an actual IPv6
address, you have to forbid one variant to have the math produce
unambiguous results.

> ... until you would provide TECHNICAL REASONS showing how (a) ..., or some revised rules, would ensure address-mapping reversibility, it is legitimate to doubt, as I do, that your new proposal work…

It's math. Doubt or opinion should not be involved.

> - Thus, two different original values of the 16-bit modified 16-bit word can, in the outgoing translation, give the same final value 0x0000. There is then no way in the reverse direction to determi…

i.e. you want "you MUST NOT use a subnet of 0xFFFF with this method"
spelled out?

Example? take the one from 3.6, but with the subnet one lower:
FD01:0203:0405:0000::1234 -> 2001:0DB8:0001:D54F::1234
On the return path: 0x2AB0 + 0xD54F = 0xFFFF

(One's Complement Arithmetic isn't -that- hard, is it?)

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Dec 2010 21:49:46 -0800

> It's math. Doubt or opinion should not be involved.

Remi:

If you would like, I can send you the code I tested this with. However, lest there be a bug in my code, may I suggest you try it for yourself?

Here are some subroutines you may find helpful:

/*
 * return number1 + number2
 */
unsigned short
add1(number1, number2)
    unsigned short  number1;
    unsigned short  number2;
{
    unsigned int    result;

    result = number1;
    result += number2;

    while (0xFFFF < result) {
        result = result + 1 - 0x10000;
    }
    return result;
}

/*
 * return number1 - number2
 */
unsigned short
sub1(number1, number2)
    unsigned short  number1;
    unsigned short  number2;
{
    return add1(number1, ~number2);
}

unsigned short
sum1(numbers, count)
    unsigned short *numbers;
    int             count;
{
    unsigned int    result;

    result = *numbers++;
    while (--count > 0) {
        result += *numbers++;
    }
    while (0xFFFF < result) {
        result = result + 1 - 0x10000;
    }
    return result;
}

I would have written those to test for "0xFFFF <= result", which would have the coercion to the 0x0000 form of a one's complement zero (0xFFFF+1-0x10000 = 0x0000), but I wanted to do that explicitly for control purposes.

Now, pick two prefixes, any two you like. I used

unsigned short  inner_init[] = {0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5};
unsigned short  outer_init[] = {0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5};

for values in 0..0xFFFF, substitute the numbers into any of the first three words (bits 0..47) of the addresses, and use the algorithm specified in the note to convert the inner prefix to the outer prefix and then back to the inner prefix. Check that the checksum is still correct, and flag it if it isn't.

I think you'll find that if you do the substitution, when the word you are updating starts with 0xFFFF, you can't predictably get it back to 0xFFFF. Any value from 0x0000 to 0xFFFE is perfectly reversible, though. I'll let you work out the reason why.

I'll post a new version tomorrow. I got some comments from Ralph Droms, which I will edit in, and I'll put the code for my test in an appendix.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Dec 2010 07:26:38 +0000

> It's math. Doubt or opinion should not be involved.

It derives from the requirement to be checksum compatible. The checksum is computed complement to 1, and under complement to 1, 0 = 0xFFFF. There is no way to enable symmetric mapping if you allow both values. This is best shown on an example:

Assume internal prefix is 0::/48, external 1::/48. Observe that:

	In order to be checksum neutral, 0:0:0:0 must map to 1:0:0:FFFE
	In order to be checksum neutral, 0:0:0:FFFF must also map to 1:0:0:FFFE
	In order to be checksum neutral, 1:0:0:FFFE may map to either 0:0:0:0 or 0:0:0:FFFF
	In order to be checksum neutral, 1:0:0:0 must map to 0:0:0:1
	In order to be checksum neutral, 1:0:0:FFFF must also map to 0:0:0:1
	In order to be checksum neutral, 0:0:0:1 may map to either 1:0:0:0 or 1:0:0:FFFF Different prefixes will lead to different values, but the same pattern.

Other prefixes result in the same issue: two internal prefixes, subnet 0 and subnet FFFF, map to the same external subnet prefix. When that external prefix is mapped back, the translator has to pick either 0 or FFFF, cannot pick both. Similarly, external subnets 0 and FFFF map to the same internal prefix, so only one of the two values can be used.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Dec 2010 15:45:09 +0100

Fred, Margaret,

Thanks to Fred for addressing my concern.
Here are further explanations and, unless I am mistaken, what I hope you will recognize as very constructive suggestions.

Le 14 déc. 2010 à 06:49, Fred Baker a écrit :
> If you would like, I can send you the code I tested this with.

Not necessary.
Mathematical reasoning should be sufficient, and see the good news below.

> I think you'll find that if you do the substitution, when the word you are updating starts with 0xFFFF, you can't predictably get it back to 0xFFFF. Any value from 0x0000 to 0xFFFE is perfectly rev…

1.
The point was not that the algorithm isn't reversible if the *word to be updated* is 0xFFFF (remember that, as recalled in the appendix below, I was at the origin of the exclusion of 0xFFFF in the subnet field in the first draft!).

It was, and remains, the LACK OF JUSTIFICATION for replacing 0xFFFF by 0x0000 *in the updated word*: 
- Let's take the /48 case
- Let A be the 16-bit word to be updated (bits 48..63 of the internal prefix)
- Let B be the computed adjustment
- Let C be the updated 16-bit word
- Let's assume, for example, that A=0xFF00 and B=0x00FF, two legitimate values that give A+B=0xFFFF
Then, why to take C=0x0000 instead of C=A+B (noting that, with C=0xFFFF, one obtains A=C-B=0x00FF).

2.
Now, a first good news:
Having worked more on the mathematics of the complete algorithm, I can now say say that *I agree that the proposed algorithm CAN work*.
It remains  that explanations are still missing and that it is MORE COMPLEX than needed.

In my understanding, the reason why the (unnecessary) replacement of C=0xFFFF by C=0x0000 isn't harmful is that:
- the only case where A+B=0x0000 is when both A=0x0000 and B=0x0000 (all other computation whose result is 0 in one's complement give 0xFFFF)
- in this case, the replacement of A=0xFFFF by A=0x0000 in the reverse computation gives the right result.

Yet, unless I miss something,the replacement of C=0xFFFF by C=0x0000 can be removed from the specification.

3.
And now, an even better good news:
In the algorithm for prefixes longer than /48, there is a search for the first 16-bit word of the IID that isn't 0xFFFF.
But in the case of ULAs, which are only local addresses, the first such word is never 0xFFFF (RFC4291 imposes that bit 7 of IIDs be =0).
Thus, bits 64..79 can be the ONLY ONES to be used.
There is no need for a search in other bits.

And now, guess what: if this same field is used in the /48 case, the EXCLUSION of the 0xFFFF subnet ID is NO LONGER NEEDED.
This is IMHO an important operational improvement at no cost.

> I'll post a new version tomorrow. I got some comments from Ralph Droms, which I will edit in, and I'll put the code for my test in an appendix.

Well, I have other comments, but a conclusion on the above would be appreciated before going on. 

Regards,
RD

APPENDIX

> De : Margaret Wasserman <[email-masked]>
> Date : 25 novembre 2008 16:52:55 HNEC
> À : Rémi Després <[email-masked]>
> Cc : Fred Baker <[email-masked]>, Behave WG <[email-masked]>
> Objet : Rép : [BEHAVE] Non reversibility of address mappings in the "NAT66" draft
> 
> 
> Hi Remi,
> 
> I ran some numbers this morning, and you are right.
> 
> If the _original_ value of the 16-bit checksum correction field is 0x0000, it will be restored to 0xFFFF, which is wrong.  The checksum correction works fine (as Fred's tests have proven), but the restoration of the value doesn't work properly.  It can be made to work properly for either 0x0000 or 0xFFFF, but I haven' t figured out a way to make it work right for both values as the information to distinguish between them is lost.
> 
> There are three approaches we can take to fix this
> ...

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Dec 2010 15:58:07 +0100

In the previous mail, in "(noting that, with C=0xFFFF, one obtains A=C-B=0x00FF)", please read "0xFF00" instead of 0x00FF.
That's obvious, but better to say it. 
RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Dec 2010 16:18:26 -0800

I disagree that a ULA cannot use a privacy address. It's an RFC 4291 prefix, end of discussion, and RFC 4291 addresses can use EUI-64 or privacy addresses.

Sigh. Regarding suppression of 0xFFFF... This was a point on which the behave working group had a long discussion and decided what they wanted to see. There are two ways to do it, but one has to pick one or the other for interoperability.

I have some code I used to verify the algorithm; it's attached. I just sat down and rewrote it to correlate it exactly to the draft - which I have just reposted to pick up some comments that Ralph Droms made. I am also including this code in an appendix.

The program has one option: whether or not the 0xFFFF suppression to 0x0000 is implemented. If the option is zero (false), I do NOT suppress 0xFFFF. If the option is 1 (true), I suppress 0xFFFF by overwriting with zero.

I only test the /48 case; the math is the same in the longer prefix cases, although the field is different. Whether I suppress 0xFFFF or not, I check every conceivable subnet number, from 0..FFFF. 

Please read the attached code and tell me what bugs I have in it.

What the code is telling me is that 0xFFFF suppression is not necessary, but having a subnet of one or the other representation of zero is a bad idea - and which is a bad idea depends on whether I do or don't suppress 0xFFFF.

[stealth-10-32-244-221:~] fred% a.out 0
outer->inner different: fd01:203:405:ffff:2:3:4:5 vs fd01:203:405:0:2:3:4:5

If we turn suppression off, a subnet number of 0x0000 converts to 0xFFFF in the destination address returning. It does this because it added the adjustment in one direction and subtracted it in the other direction, and in one's complement arithmetic, where x-x = x + (-x) = zero, it results in the negative zero.

[stealth-10-32-244-221:~] fred% a.out 1
outer->inner different: fd01:203:405:0:2:3:4:5 vs fd01:203:405:ffff:2:3:4:5

If we turn suppression on, a subnet number of 0xFFFF converts to 0x0000 in the destination address returning.

Think about it. For simplicity, let's calculate x-x in a two bit one's complement number field.

00-00 = 00 + (-00) = 00 + 11 = 11
01-01 = 01 + (-01) = 01 + 10 = 11
10-10 = 10 + (-10) = 10 + 01 = 11
11-11 = 11 + (-11) = 11 + 00 = 11

So, if I don't suppress 0xFFFF, a subnet number of 0 comes back as 0xFFFF, and if I do, the suppression makes a subnet number of 0xFFFF come back as zero. I can or I can't have the suppression, but I can't have a subnet number of one of the two representations of zero. By convention, in the Internet, per RFC 1071 we suppress 0xFFFF, and that means that I forbid the use of subnet 0xFFFF as well.

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Dec 2010 10:02:43 +0100

> I disagree that a ULA cannot use a privacy address. It's an RFC 4291 prefix, end of discussion, and RFC 4291 addresses can use EUI-64 or privacy addresses.
Oops.
Fortunately, I didn't write that "ULA cannot use a privacy address", because I never believed that!
But I see how you derived such an assumption: the reason I gave for IIDs of local addresses never start with 0xFFFF was incomplete.
The complete reason is that *bit 7 OR bit 6 is 0* in these addresses. 
(Bit 7, the "g" bit, is 0 in modified EUI64 addresses; bit 6, the "inverted "u" bit, is 0 in privacy addresses.)

> Sigh. Regarding suppression of 0xFFFF... This was a point on which the behave working group had a long discussion and decided what they wanted to see.

> There are two ways to do it, but one has to pick one or the other for interoperability.
Well understood, and agreed.

> Please read the attached code and tell me what bugs I have in it.

I didn't say there is a bug in your code?
On the contrary, I said in my mail that, although the current design was more complex than needed, "the proposed algorithm CAN work". 

But here again my explanation was incomplete so that your interpretation became legitimate.
The intent was to discuss address modification *ONLY in the outgoing direction*. 
The sentence that made it clear disappeared during the editing process :-(.

> If we turn suppression off, a subnet number of 0x0000 converts to 0xFFFF in the destination address returning.

> It does this because it added the adjustment in one direction and subtracted it in the other direction, and in one's complement arithmetic, where x-x = x + (-x) = zero, it results in the negative zero.
> 
> <nat66.c>

Agreed on all of this but, as said above, this is needed only in the incoming direction.

All my apologies for the two incomplete explanations I gave. 
With the two clarifications-corrections above, I believe that the substantial simplification I suggest keeps its value.

Regards,
RD

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Dec 2010 15:17:22 +0000

Fred,

Your program does not test for collision of the output, i.e. 2 inputs giving the same output.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Dec 2010 09:47:07 -0800

> Your program does not test for collision of the output, i.e. 2 inputs giving the same output.

Good catch. Thanks. See attached.

The output is the same.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Dec 2010 18:22:51 +0000

So I ran the program. With input "suppress = 0" I get:
	outer->inner different: calculated: fd01:203:405:ffff:2:3:4:5 inner: fd01:203:405:0:2:3:4:5
and with "suppress = 0xFFFF" I get:
	outer->inner different: calculated: fd01:203:405:0:2:3:4:5 inner: fd01:203:405:ffff:2:3:4:5

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 9:47 AM
To: Christian Huitema
Cc: Rémi Després; Margaret Wasserman; NAT66 HappyFunBall
Subject: Re: [nat66] Constructive suggestions

The output is the same.

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Dec 2010 10:28:18 -0800

> 	outer->inner different: calculated: fd01:203:405:0:2:3:4:5 inner: fd01:203:405:ffff:2:3:4:5

Yes. I went through that in detail yesterday.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Dec 2010 18:39:37 +0000

So we seem to agree that if we want to adjust for checksum neutrality by changing the 16 bit subnet number (bit 48-63), we cannot have both subnet 0 and subnet 0xFFFF. That may be OK in practice, e.g. create deployment rules that reserve one of 0 or 0xFFFF for internal only operation. In any case, we should have a more prominent discussion of the issue than the single line statement in the current draft.

Rémi proposed an alternative where we adjust for checksum by changing the bits 64-79, on the rationale that the value 0xFFFF is not encountered in practice in these bits. I do not like that suggestion, because it makes assumption on the structure of the host identifier that are difficult to control. We cannot exclude that some device manufacturers or some software developers will come up in the future with host identifiers that falsify Rémi's assumption. When that happen, the failures will be very hard to debug and fix. They will trigger a butting of heads between the site admin who deployed the NAT66, the local user whose device does not work, the manufacturer of the device and the developer of the software. In contrast, a simple rule like "reserve subnet 0xFFFF for subnet that will not cross the NAT" is entirely under the control of the site admin, thus much less likely to cause operational problems.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Dec 2010 11:04:11 -0800

> So we seem to agree that if we want to adjust for checksum neutrality by changing the 16 bit subnet number (bit 48-63), we cannot have both subnet 0 and subnet 0xFFFF. That may be OK in practice, e…

No problem.

> Rémi proposed an alternative where we adjust for checksum by changing the bits 64-79, on the rationale that the value 0xFFFF is not encountered in practice in these bits. 

Which, btw, I disagree with. Privacy addresses are in essence 64 bit random numbers, and I don't see anything to prevent them putting 0xFFFF in the bit field. Unlikely, perhaps, but not precluded.

> I do not like that suggestion, because it makes assumption on the structure of the host identifier that are difficult to control. We cannot exclude that some device manufacturers or some software developers will come up in the future with host identifiers that falsify Rémi's assumption. When that happen, the failures will be very hard to debug and fix. They will trigger a butting of heads between the site admin who deployed the NAT66, the local user whose device does not work, the manufacturer of the device and the developer of the software. In contrast, a simple rule like "reserve subnet 0xFFFF for subnet that will not cross the NAT" is entirely under the control of the site admin, thus much less likely to cause operational problems.

Very much agree.

Is there some text you'd like to see in the draft, or are you simply making a comment?

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Dec 2010 09:34:25 +0100

> Which, btw, I disagree with. Privacy addresses are in essence 64 bit random numbers, and I don't see anything to prevent them putting 0xFFFF in the bit field. Unlikely, perhaps, but not precluded.

To see why 0xFFFF is indeed precluded, see section 3.2.1 of RFC 4941 which says:
"A randomized interface identifier is created as follows:
...
Take the leftmost 64-bits of the MD5 digest and set bit 6 (the leftmost bit is numbered 0) to zero.  This creates an interface identifier with the universal/local bit indicating local significance only."

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Dec 2010 11:02:16 +0100

Le 15 déc. 2010 à 19:39, Christian Huitema a écrit :

> So we seem to agree that if we want to adjust for checksum neutrality by changing the 16 bit subnet number (bit 48-63), we cannot have both subnet 0 and subnet 0xFFFF.

Yes.

> That may be OK in practice, e.g. create deployment rules that reserve one of 0 or 0xFFFF for internal only operation.

Since this restriction can be easily avoided, keeping it would a criticizable design.
Here is a the proposal to avoid it.
(a) NPTv6 discards packets whose translatable addresses has IIDs start with 0xFFFF (with returned ICMPv6 error messages)
(b) It always makes its checksum adjustments in address bits 64..79.
(c) In both directions, if the computation of the adjusted field gives 0xFFFF, this value is replaced by 0x0000  

It isn't proved that, in practical NPTv6 configurations, the replacement of 0xFFFF by 0x0000 is needed in the outgoing direction, but:
- At least it doesn't hurt.
- The symmetry of the replacement rule can be viewed as a simplification of the specification.
- Even if NPTv6 might be cascaded (a subject I would prefer to leave aside at this stage), this ensures that adjusted IIDs would also never start with 0xFFFF.
(The fact that the replacement applies to both directions is a change from the initial proposal.)     

> In any case, we should have a more prominent discussion of the issue than the single line statement in the current draft.
> 

More than their being "not encountered in practice", it is that host IIDs starting with 0xFFFF are formally precluded.
(Fred said in another mail that they are "unlikely, perhaps, but not precluded" because of privacy addresses. But this was overlooking that privacy addresses can never start wit 0xFFFF (their bit 6 is always forced to 0).

> I do not like that suggestion, because it makes assumption on the structure of the host identifier that are difficult to control.

In my understanding, checking that a precluded IID value isn't used fits with the general idea of prevention against error propagation. 
Ensuring that a subnet ID which is otherwise permitted isn't used when NPTv6 is activated is likely to create operational problems.
Note in particular that all subnet values are permitted with a NAT66 that isn't NPTv6 (an NAPTv6).

> We cannot exclude that some device manufacturers or some software developers will come up in the future with host identifiers that falsify Rémi's assumption. When that happen, the failures will be very hard to debug and fix.

NPTv6, when having to translate an address whose IID starts with 0xFFFF should, as usual, drop the invalid packet and return an ICMPv6 message with an error code. This code should signal an invalid IID format.
 
> They will trigger a butting of heads between the site admin who deployed the NAT66, the local user whose device does not work, the manufacturer of the device and the developer of the software. In contrast, a simple rule like "reserve subnet 0xFFFF for subnet that will not cross the NAT" is entirely under the control of the site admin, thus much less likely to cause operational problems.

I don't see that:
- Bugged IID formats are easy to detect, and are likely to be also detectable by other functions than NPTv6. 
- I foresee more butting of heads if the 0xFFFF subnet prefix, perfectly legitimate without NPTv6, is forbidden with it. (Keeping designs simple and orthogonal generally simplifies operations).

Conclusion: I still hope that my proposal, updated as above, will be understood as a constructive one, and as one whose sole purpose is to improve IETF originated designs.

Regards,
RD

---

From: jefsey <[email-masked]>
Date: Thu, 16 Dec 2010 13:21:02 +0100

At 11:02 16/12/2010, Rémi Després wrote:
>- Bugged IID formats are easy to detect, and are likely to be also 
>detectable by other functions than NPTv6.

What is a "bugged IID format". On a use point of view we consider 
that the IDv6 64 bits area is without any constraint? That is simplicity.
jfc

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Dec 2010 13:59:47 +0100

Le 16 déc. 2010 à 13:21, jefsey a écrit :

> What is a "bugged IID format". On a use point of view we consider that the IDv6 64 bits area is without any constraint? That is simplicity.

But it isn't what RFCs that specify link layer protocols say.
RD

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Dec 2010 05:49:07 -0800

On Dec 16, 2010, at 2:02 AM, Rémi Després wrote:

> Since this restriction can be easily avoided

You seem to have not followed my email thread. Could I trouble you to go read it again?

---

From: jefsey <[email-masked]>
Date: Thu, 16 Dec 2010 18:11:46 +0100

>But it isn't what RFCs that specify link layer protocols say.

Could you not help in being more specific ? We need to know what we 
will certainly intend to disregard and how we will do it. As users 
was we are not interested in IPv6 as such, we are interested in a 
nat46/66 64 bits unconstrained addressing space, it being agnostic to 
any internet/non-internet technology and IPv4/IPv6 addressing plan.

jfc