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

[Ray Hunter <[e-mail]>]

inline.

> Tore Anderson <mailto:[e-mail]>
> 24 June 2015 09:32
> * Ray Hunter<[e-mail]>
>
>> 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"
>>
>> Surely that should be a "longest-matching-prefix based on CIDR
>> [RFC4632]"
>
>> 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.
>
> 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
Correct. Operators can shoot themselves in the foot.
>
> 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.
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.
>
> That said, do you think the draft should discuss what to do when
> multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example:
yes.
>
> 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.
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>
/



>
>> 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./
>
> Good idea, we'll add this. A reference to RFC6724 is probably
> appropriate here too.
Agreed.
>
>> Nits
>> [...]
>
> Will fix. Thanks again!
>
> Tore
> Ray Hunter <mailto:[e-mail]>
> 23 June 2015 22:05
>
>
>
>
> 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
>
>