Subject: Re: [iucg] [nat66] I'd appreciate comments

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

At 20:03 06/12/2010, Fred Baker wrote:
>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.

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

>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
>
>_______________________________________________
>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: 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

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

>> 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
>
> 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: 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
> 
> 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
> 
> and SHOULD store the randomly generated prefix [in] non-volatile storage for continued use.
>

---

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
>
>