Subject: [nat66] "Technical points" about the mrw-nat66 specification.

From: Rémi Després <[email-masked]>
Date: Fri, 29 Oct 2010 18:46:54 +0200

Hi, Margaret, Fred,

Here are a few questions/comments about the document itself (leaving aside for the time being considerations on its purpose, about which we apparently have so far different views).

1.  Sec 8, 2nd paragraph
Isn't it bits 49-64 instead of 34-48?

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.
- 
3. Sec 13 has "it is RECOMMENDED that NAT66 devices include an IPv6 firewall function, and the firewall function SHOULD be configured by default to block all incoming connections."
Wouldn't a reference to draft-ietf-v6ops-cpe-simple-security be appropriate?

4. Sec 15 has a typo in my name. 

Regards,
RD

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Oct 2010 12:52:14 -0400

Hi Remi,

Thanks for the feedback.

> Isn't it bits 49-64 instead of 34-48?

Yes, this will be fixed.  Actually, it is 33-48.
>
> 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 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.

Why do you think special wording is needed for this case?
> -
> 3. Sec 13 has "it is RECOMMENDED that NAT66 devices include an IPv6  
> firewall function, and the firewall function SHOULD be configured by  
> default to block all incoming connections."

Yes.
> 4. Sec 15 has a typo in my name.

Oh, sorry.  I'll fix that.

Margaret

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 10:25:46 -0700

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

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Oct 2010 13:39:59 -0400

Hi Fred,

> I'm missing the reference. Is this from private email?

No reference...  I mistyped...  I think this is the same problem that  
you, Fred, found earlier.  There is a place in the document where it  
says 34-48 and it should say 48-63 (not 49-64 as Remi indicated, and  
not 33-48 as I indicated).

I need to take some time when I don't have any interuptions and look  
over the algorithm very closely, to make sure that it is exactly  
correct.

> If you're discussing the bit numbering of the address (MRW -  
> remember I pointed this out to you?)...
>
> 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.

Exactly.

Margaret

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 11:20:20 -0700

> Wouldn't a reference to draft-ietf-v6ops-cpe-simple-security be appropriate?

I-D.ietf-v6ops-cpe-simple-security is about residential gateways, with special emphasis on unmanaged configuration.  I thought we didn't believe that was an appropriate scenario for NAT66 usage?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 11:29:33 -0700

> I-D.ietf-v6ops-cpe-simple-security is about residential gateways, with special emphasis on unmanaged configuration.  I thought we didn't believe that was an appropriate scenario for NAT66 usage?

I don't see why not. Note that, as I pointed out the other day, NTT is pushing the work in MIF as a requirement for them to not deploy network prefix translation and is specifically pointing to this draft as their alternative. Their scenario is a mandated multihoming of every Japanese home. Their scenario is common DSL last mile that connects each of the ISPs (including NTT's ISP business) and also a separate video-on-demand network. So every home has at least the national video-on-demand service, which is from a topology/upstream perspective a separate service provider operated by NTT but only provides access to the video content, plus as many ISPs as it wants to contract with. Every home is multihomed, every ISP including the video service implements BCP 38, and if we don't sort out the issues that Arifumi has been wrestling with for however long, they plan to deploy NAT66 to the home.

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 29 Oct 2010 11:45:38 -0700

On Oct 29, 2010, at 11:29, Fred Baker wrote:
> 
> ...and the firewall function SHOULD be configured by default to block all incoming connections.

Also, do you really want to have *that* discussion all over again?

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 11:50:27 -0700

> Also, do you really want to have *that* discussion all over again?

Actually, no. Thanks for pointing it out - I missed that in my review of this version. Yes, a reference to cpe-simple-security would be the right thing.

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 11:57:05 -0700

---

From: Rémi Després <[email-masked]>
Date: Sat, 30 Oct 2010 08:55:31 +0200

> Yes, this will be fixed.  Actually, it is 33-48.

I do agree with your last e-mail on the subject: the right value is 48-63! 

> It is not necessarily the case that a NAT66 device will be aware that there are other NAT66 devices attached to the same network.

With the spec as is, 0xFFFF must be avoided in bits 48-63 of ALL internal addresses it they are subject to stateless NAT66.
 
(In the inbound direction, where this field should be restored to 0xFFFF, it is restored to 0x0000. 
Due to "If the resulting value is 0xFFFF, it is changed to 0x0000", the mapping isn't completely 1:1. 

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

> Why do you think special wording is needed for this case?

The current sentence suggests that, if each CPE of a multi-CPE site has only one interface, each one MAY have 0xFFFF in bits 48-63.
In my understanding, this is wrong.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 30 Oct 2010 10:00:49 +0200

> I-D.ietf-v6ops-cpe-simple-security is about residential gateways, with special emphasis on unmanaged configuration.  I thought we didn't believe that was an appropriate scenario for NAT66 usage?

I strongly agree with you that simple CPEs (unmanaged ones) shouldn't have NAT66!
As you know, I even instantly suggest that they should by default be transparent (i.e. not filtering incoming connections).

The point made is just that, should stateless NAT66 CPEs exist at all and be combined wit a FW's, their level of security should at least that which has been carefully documented in your draft.

Besides this, as you may have noticed, I still have serious personal doubts that stateless NAT66's are sufficiently useful to be deployed.
But this is a different point.

Regards,
RD

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Oct 2010 07:20:46 -0400

Hi Remi,

On Oct 30, 2010, at 2:55 AM, Rémi Després wrote:
>
> With the spec as is, 0xFFFF must be avoided in bits 48-63 of ALL  
> internal addresses it they are subject to stateless NAT66.
>

The only addresses that are translated by the NAT66 box are the local  
addresses:  source address for outbound packets and destination for  
inbound packets.  The specification already states that sites that  
deploy NAT66 may not use a subnet with 0xFFFF in bits 48-63.   This  
applies to both the internal and global prefixes.

BTW, this only applies if the site is using a prefix length of /48 or  
shorter.  If a longer prefix is used, any subnet value can be used  
because the correction is done in the IID.  I should check and make  
sure that the spec is clear on that.
>
>
> The current sentence suggests that, if each CPE of a multi-CPE site  
> has only one interface, each one MAY have 0xFFFF in bits 48-63.

I'll read over the text and see if I can make it clearer.  In a case  
where NAT66 is used with a prefix length of /48 or shorter (even just  
one box with one interface), subnets ending in 0xFFFF (all ones in  
bits 48-63) can't be used.  Network administrators will need to make  
sure that is true, as par of installing NAT66.

Margaret