On Oct 29, 2010, at 9:52 AM, Margaret Wasserman wrote:
>
> Hi Remi,
>
> Thanks for the feedback.
>
> On Oct 29, 2010, at 12:46 PM, Rémi Després wrote:
>> 1. Sec 8, 2nd paragraph
>> Isn't it bits 49-64 instead of 34-48?
>
> Yes, this will be fixed. Actually, it is 33-48.
>>
I'm missing the reference. Is this from private email?
If you're discussing the bit numbering of the address (MRW - remember I pointed
this out to you?), RFCs follow the historic IBM bit numbering scheme, aka
"Network Byte Order" - the most significant bit is bit zero, we count towards
the least significant bit, and the bytes are big-endian. You're find that in
RFC 791, for example; this from page 12 of that spec:
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
Bit 6-7: Reserved for Future Use.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
It's also found in RFC 4291, which is important in this context. An example
from 4291 - a MAC Address is described as
0 0 0 1 1 2
|0 7 8 5 6 3|
+----+----+----+----+----+----+
|cccc|ccug|cccc|cccc|cccc|cccc|
+----+----+----+----+----+----+
That makes the enumeration of the IPv6 Address:
0 15.16 31.32 47.48 63.64 79.80 95.96 111.112 127
+------+------+------+------+------+------+------+------+
| | | |
| Prefix |Subnet| Endpoint Identifier |
| | | |
+------+------+------+------+------+------+------+------+
The exact width of the subnet field is of course variable, but per RFC 4291
that's where we will find it - in bits 48..63.
>> 2. Sec 11, last paragraph, (rightly) has "NAT66 devices with more than one
>> internal interface SHOULD assign a (non-0xFFFF) subnet"
>> This isn't sufficient.
>> It must also apply to networks that have several NAT66 devices with a single
>> interface in each.
>> Besides, an explanation of why it is so should IMHO be added.
>
> It is not necessarily the case that a NAT66 device will be aware that there
> are other NAT66 devices attached to the same network. It is up to the
> network administrators to determine if multiple NAT66 devices on a network
> will be configured to use the same internal prefix or different ones.
Since the mapping is algorithmic, it's not obvious to me why they would need
to. There is value in it if we use stateful mapping, so that state can be
propagated. But not in stateless mapping.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
