[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] Proposed Last Call based revisions to IKEv2
On Thu, May 27, 2004 at 11:20:42AM -0700, Charlie Kaufman wrote:
> Can I get a ruling on this one?
If you have the document open and we need to submit a new I-D anyway,
my bias would be to fix it, on the grounds of consistency with
INTERNAL_IP6_SUBNET. It's easier to fix it now rather than later, and
will probably reduce confusion for implementors in the future.
Although this does change the on-the-wire encoding, it has the feel of
an editorial fix. However, I don't feel strongly about about this,
but you asked for a ruling. Tell folks want. If anyone objects, they
have 24 hours to do so. If not, go ahead and push the ID out.
- Ted
> 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