[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] Proposed Last Call based revisions to IKEv2
Can I get a ruling on this one?
Notes:
1) The context in which this occurs is when an IKE initiator requests an
IPv6 address on the responder's internal network so that it can use it
as a source address in its tunneled packets and responses will be routed
back to the IKE responder. This is important when the IKE responder is
not on the path between the IKE initiator and all of the nodes it will
be talking to over the SA. In almost all cases, the NETMASK is
irrelevant. If NETMASK were relevant, it should be included in the
INTERNAL_IP6_SUBNET attribute, which is already encoded as proposed
below.
2) Perhaps I'm confused, but it's my understanding that a NETMASK is
just a very inefficient encoding of a prefix length (both in IP4 and
IP6). That a NETMASK containing anything other than a series of '1' bits
followed by a series of '0' bits is unsupported by almost everything.
So I would favor leaving it alone, but I don't think it will break
anything if we change it.
--Charlie
-----Original Message-----
From: Darren Dukes (ddukes) [mailto:ddukes@cisco.com]
Sent: Wednesday, May 26, 2004 7:49 AM
To: 'Theodore Ts'o'; Charlie Kaufman
Cc: ipsec@ietf.org
Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2
I've noticed a problem in the configuration payload section that I
believe
Steven Kent, and another individual had warned me about many months ago,
and
I thought I had requested a change for but apparently never did. The
problem is that an INTERNAL_IP6_NETMASK field is defined and this makes
no
sense in IPv6. The change I propose now is to extend the
INTERNAL_IP6_ADDRESS type to 17 bytes, the additional byte will be the
IPv6
address prefix-length and INTERNAL_IP6_NETMASK should be removed from
the
document.
I apologize to the working group for such an extremely late change,
hopefully it can be reviewed and accommodated.
On page 78...
Change:
INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets
To:
RESERVED 9
Change:
INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets
To:
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
On page 79...
Change:
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or
private address and MAY be a private address on the Internet.
Multiple internal addresses MAY be requested by requesting
multiple internal address attributes. The responder MAY only
send up to the number of addresses requested.
To:
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or
private address and MAY be a private address on the Internet.
Multiple internal addresses MAY be requested by requesting
multiple internal address attributes. The responder MAY only
send up to the number of addresses requested. The
INTERNAL_IP6_ATTRIBUTE is made up of two fields; the first
being a 16 octet IPv6 address the second being a one octet
prefix-length as defined in [ADDRIPV6].
Also on page 79...
Change:
o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal
network's netmask. Only one netmask is allowed in the request
and reply messages (e.g., 255.255.255.0) and it MUST be used
only with an INTERNAL_ADDRESS attribute.
To:
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only
one netmask is allowed in the request and reply messages
(e.g., 255.255.255.0) and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute.
(Removed INTERNAL_IP6_NETMASK and change INTERNAL_ADDRESS to
INTERNAL_IP4_ADDRESS.)
Thanks,
Darren
> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
> On Behalf Of Theodore Ts'o
> Sent: Tuesday, May 25, 2004 4:14 PM
> To: Charlie Kaufman
> Cc: ipsec@ietf.org
> Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2
>
>
> On Sat, May 15, 2004 at 10:50:15PM -0700, Charlie Kaufman wrote:
> > Based on the discussion on the list, I believe these are
> the final edits
> > to IKEv2. If anyone disagrees, please speak up before I
> send out -14.
>
> Charlie,
>
> It's been a week and we received two suggestions. One was Paul's very
> good suggestion keep the changes regarding fragmentation handling in
> RFC-2401bis, which has the advantage of avoiding another IETF-wide
> last call on your document. The other was William Dixon's suggestion
> for providing better advanced handling support, which as Russ has
> pointed out can be done independently without blocking the progress of
> the IKEv2 draft. Barbara and I believe you should accept Paul's
> suggestion, and not make any changes to IKEv2 in response to points
> raised by William Dixon on this thread. If he would like to do that
> work as a separate draft, in another working group, it appears that
> the Area Directors will be receptive to such an approach.
>
> If you could get -14 published at your earlier convenience, we will
> then inform Russ that all of the comments raised during the IETF last
> call process have been resolved, and he should proceed with the
> getting IESG approval for publishing IKEv2 as a standards-track RFC.
>
> Many thanks for all of your very hard work,
>
> - Ted and Barbara
>
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec