Subject: [IPsec] Issue #23 Example IP address ranges

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2008 15:10:27 +0300

> >     The first of the two TS payloads is known as TSi (Traffic Selector-
> >     initiator).  The second is known as TSr (Traffic Selector-responder).
> >     TSi specifies the source address of traffic forwarded from (or the
> >     destination address of traffic forwarded to) the initiator of the
> >     CHILD_SA pair.  TSr specifies the destination address of the traffic
> >     forwarded to (or the source address of the traffic forwarded from)
> >     the responder of the CHILD_SA pair.  For example, if the original
> >     initiator requests the creation of a CHILD_SA pair, and wishes to
> >     tunnel all traffic from subnet 192.0.1.* on the initiator's side to
> >     subnet 192.0.2.* on the responder's side, the initiator would include
> >     a single traffic selector in each TS payload.  TSi would specify the
> >     address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
> >     address range (192.0.2.0 - 192.0.2.255).  Assuming that proposal was
> >     acceptable to the responder, it would send identical TS payloads
> >     back.  (Note: The IP address range 192.0.2.* has been reserved for
> >     use in examples in RFCs and similar documents.  This document needed
> >     two such ranges, and so also used 192.0.1.*.  This should not be
> >     confused with any actual address.)
> 
> I think we should use only the one example network that has been
> reserved for that purpose, i.e get the rid of the 192.0.1.* address
> space. As we do use ranges in all cases in the IKEv2, there is no
> reason why the networks need to be /24 subnets. How about using
> 
> 192.0.2.0/25 (i.e. 192.0.2.0 - 192.0.2.127) and
> 192.0.2.128/25 (i.e. 192.0.2.128 - 192.0.2.255) instead.
> 
> ===Not done. People really relate to /24s much better.

And that is the reason we still do have implementations which cannot
do ranges but only do subnets. As IKEv2 do use only IP-ranges, I think
the examples should always use ranges, and should NOT use any /24 or
192.0.1.* style expression ever.

If implementors do not understand how ranges work, they should learn
now before starting to implement IKEv2 :-)

I myself think ranges like 192.0.1.32 - 192.0.1.39 are much simplier
than 192.0.1.32/29, especially when you are reading them. Writing and
generating them might be bit harder, but that is done only once while
writing, it is the reading part that is the more important for this
document. When you need to convert subnet like 192.0.1.192/28 to
range to be used in the TS it just adds one extra complication for the
implementor. 

> 
> Otherwise we might want to add comment to all other places having that
> 192.0.1.* network (which is actually used much more than the real
> example network of 192.0.2.*).
> 
> ===Not done. Developers reading this document understand what is going on.

I think we should follow RFC 3330 and use only that network reserved
for examples, especially as there is nothing in the IKEv2 that
actually requires using any subnets. We could use 192.0.2.0-192.0.2.99
and 192.0.2.150-192.0.2.249 also if we just felt like it, and I do not
really think it would make our examples harder to understand.

In the configuration payloads case we do still need to restrict
ourself to some kind of subnets as INTERNAL_IP4_NETMASK and
INTERNAL_IP4_SUBNET attributes do not use ranges, but even there is
nothing that requires using /24 networks (and some of the examples
already use /26 network there).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec