[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