[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments



Hi Charlie.

Re: 2.19.  I don't understand your objection.  In the example you only use
one address (10.168.219.202) and one subnet (10.168.219.0/24).  Why not
replace it with 192.0.2.202 and 192.0.2.0/24 ?  You could also change the
responder TSr to be identical to the initiator TSr, because I think this is
the way most remote-access works - the client can send whatever traffic to
the gateway, not just to the remote-client subnet.


-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
Charlie Kaufman
Sent: Monday, July 19, 2004 2:14 AM
To: ipsec@ietf.org
Subject: [Ipsec] Proposed changes to IKEv2 based on IESG comments

The following are the IESG comments on IKEv2 annotated with what I did
to address them in the IKEv2 spec. In most cases, the needed correction
or clarification was obvious. But in some cases, I had to guess what to
do (or explain why I believed no action was necessary). In one case (3rd
item
under controversial - IRAC/IRAS with IPv6 - I don't know what to do and
need guidance). I'm posting this to solicit objections, feedback, and
ideas.

            --Charlie



********MOST LIKELY TO BE CONTROVERSIAL********
>2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918
>addresses.

RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in
documentation. Unfortunately, negotiation of traffic selectors requires
specification of two subnets. They are currently taken from 10.*, which is
reserved for local use. While in theory, on might divide 192.0.2.0 into
multiple subnets, this is likely in practice to be confusing.

<snip>


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec