Subject: [v6ops] draft-ietf-v6ops-siit-eam WGLC

From: [email-masked]
Date: Sun, 21 Jun 2015 11:00:03 -0700

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 23 Jun 2015 22:05:39 +0200

> continues for another week.  Please feel free to comment on it.

I have read this draft. It is very well written, the intention is clear, 
and I support it.

Three comments:

Comment 1
Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that of 
the IPv4 address being translated." and "an IPv6 Prefix identical to 
that of the IPv6 address being translated"

Surely that should be a "longest-matching-prefix based on CIDR [RFC4632]"

Comment 2
Operational complexity:

Suggest Adding at the end of this paragraph
/Source address selection rules on hosts may not have enough information 
to be able to select the appropriate source address for outbound 
sessions in the presence of SIIT./

Comment 3
/  Overlapping EAMs SHOULD be considered an error, and attempts to
    insert them into the EAMT SHOULD be blocked. The behaviour of an
    SIIT implementation when overlapping EAMs are present in the EAMT is
    left undefined./

I believe that this is an unnecessary restriction for correct 
specification/operation provided CIDR/longest-matching-prefix is specified.

Nits

s/The IPv4-translatable IPv6 addresses must not only be assigned to
       the IPv6 nodes participating in SIIT/
The IPv4-translatable IPv6 addresses not only has to be assigned to
       the IPv6 nodes participating in SIIT/

s/number his entire/number their entire/
s/addresses he assigns/addresses they assign/

s/are REQUIRED to/MUST/

regards,
RayH

---

From: Ca By <[email-masked]>
Date: Tue, 23 Jun 2015 14:02:02 -0700

I have read draft-ietf-v6ops-siit-eam WGLC and find it useful and mature
enough to move forwards

Regards,
Cameron

On Sun, Jun 21, 2015 at 11:00 AM, <[email-masked]> wrote:

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

---

From: Tore Anderson <[email-masked]>
Date: Wed, 24 Jun 2015 09:32:56 +0200

* Ray Hunter <[email-masked]>

> I have read this draft. It is very well written, the intention is
> clear, and I support it.

Hi Ray -- thank you!

> Comment 1
> Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that
> of the IPv4 address being translated." and "an IPv6 Prefix identical
> to that of the IPv6 address being translated"
> 

>    SIIT implementation when overlapping EAMs are present in the EAMT
>    is left undefined./
> 

The reasoning behind this restiction was that it would otherwise be
possible to create a situation that does not facilitate bi-directional
communcation. For example:

EAM #1: 192.0.2.1/32,    2001:db8::/32
EAM #2: 198.51.100.1/32, 2001:db8:c000:201::/128

This would cause 192.0.2.1 to be translated to 2001:db8:c000:201::,
which in turn would be translated to 198.51.100.1. That will likely
break whatever use-case was intended. Then again, I suppose it might as
well be allowed. If the operator shoots himself in the foot he can deal
with that himself...so, yeah, we'll lift the restriction and use CIDR.

That said, do you think the draft should discuss what to do when
multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example:

EAM #1: 192.0.2.0/24, 2001:db8:a::/48
EAM #2: 192.0.2.0/24, 2001:db8:b::/48

Or:

EAM #1: 192.0.2.1/32,    2001:db8::/128
EAM #2: 198.51.100.1/32, 2001:db8::/128

Suggested text would of course be very welcome.

> sessions in the presence of SIIT./

Good idea, we'll add this. A reference to RFC6724 is probably
appropriate here too.

> [...]

Will fix. Thanks again!

Tore

---

From: Ray Hunter <[email-masked]>
Date: Wed, 24 Jun 2015 14:22:17 +0200

inline.

> Tore Anderson <mailto:[email-masked]>
> 24 June 2015 09:32
> * Ray Hunter<[email-masked]>
>
Correct. Operators can shoot themselves in the foot.
> with that himself...so, yeah, we'll lift the restriction and use CIDR.
I think it's fair to give a warning about the dangers of overlapping 
ranges, or different length suffixes, potentially leading to problems 
with two way communication, but I don't think that it constitutes a 
"SHOULD NOT" or "MUST NOT" in the specification.
> multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example:
yes.
> Suggested text would of course be very welcome.
Suggested text:
/
<t>The translation algorithm specified in section 3.3 relies on 
longest-mask-matching of source and destination addresses to select the 
appropriate entry in the Explicit Address Mapping Table. Operators of 
SIIT devices should note that configuring overlapping or identical 
prefixes in the EAM table may create problematic cases where it is not 
possible to guarantee symmetric address translations, and thus two way 
communication may not be possible.
</t> <t>
In the first example EAM table below, where the IPv4 ranges do not 
overlap but the IPv6 ranges do:
</t> <t>
EAM #1: 192.0.2.1/32, 2001:db8::/32
</t> <t>
EAM #2: 198.51.100.1/32, 2001:db8:c000:201::1/128
a packet with a source IPv4 address of 192.0.2.1 may possibly be 
translated to 2001:db8:c000:201::1. However, any return packets with 
IPv6 source address 2001:db8:c000:201::1 will trigger a longest prefix 
match with 2001:db8:c000:201::1/128, and will thus be translated to the 
incorrect IPv4 prefix (198.51.100.1/32).
</t> <t>
In the second example EAM table below, where the IPv6 ranges are 
identical but the IPv4 ranges do not overlap at all:
</t> <t>
EAM #1: 192.0.2.1/32, 2001:db8::/128
</t> <t>
EAM #2: 198.51.100.1/32, 2001:db8::/128
</t> <t>
packets with a source IPv4 address of 192.0.2.1 or 198.51.100.1will both 
be translated to 2001:db8::. Once again, SIIT will not be able to 
determine the correct IPv4 prefix to apply for translating return 
packets in a deterministic way (SIIT does not maintain  state). The 
behaviour of SIIT is unspecified in this case.
</t> <t>
In the third example EAM table below, the IPv6 ranges and IPv4 ranges do 
not overlap with any other entries, but they potentially contain 
differing numbers of hosts:
</t> <t>
EAM #1: 192.0.2.0/24, 2001:db8::c000/48
</t> <t>
packets with a source IPv6 address of 2001:db8::c000::0/128 to 
2001:db8::c000::ff/128 may be translated to 192.0.2.0 to 192.0.2.255 
respectively. But if packets arrive from an IPv6 source address of 
2001:db8::c000::ffff, there may not be any IPv4 addresses available to 
perform the address translation in an unambiguous way. An implementation 
could theoretically determine which IPv6 hosts are actually active or 
visible on the IPv6 side of the SIIT over a longer time frame, and 
dynamically adjust the contents of the SIIT EAM table so that the SIIT 
maintains a one-to-one unambiguous symmetric mapping of IPv4 to IPv6 
addresses, but that is outside the scope of this paper.
</t> <t>
Operators SHOULD avoid use of overlapping prefixes in the EAM table. 
Entries with different suffix lengths for IPv4 and IPv6 SHOULD also be 
avoided. Implementations MAY provide a warning if such ambiguous entries 
are detected in the EAM table.
</t>
/

> Good idea, we'll add this. A reference to RFC6724 is probably
Agreed.
>
>> Nits
>> [...]
>
> Will fix. Thanks again!
>
> Tore
> Ray Hunter <mailto:[email-masked]>
> 23 June 2015 22:05
>
>
>
>
> /Source address selection rules on hosts may not have enough 
> information to be able to select the appropriate source address for 
> outbound sessions in the presence of SIIT./
>
>
> Comment 3