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 protected]>
> 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.
>
> 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.
>
> _______________________________________________
> iucg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/iucg
>
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
