Subject: RE: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes

From: "Charlie Kaufman" <[email-masked]>
Date: Fri, 18 Feb 2005 12:15:08 -0800

The current language is (by my reading at least) self-inconsistent,
which makes it a good candidate for fixing in AUTH48.

The inconsistency is that the Attribute Type table lists
INTERNAL_IP4/6_SUBNET as not multivalued while the text says that
multiple values can be requested and returned. From the discussion
below, I gather that the text is right and the table should say "YES".
(This also affects the IANA registry).

The syntax of the CFG_REQUEST with respect to multivalued attributes is
not what I would have designed, but I believe it is unambiguous and I
see no compelling reason the change it at this late date. For all but
two of the multivalued attributes, the syntax allows the field to be
requested multiple times in the request (which seems silly) and allows
the responder to return all of the values of the requested attribute
even if only one is requested. I can think of no reason why someone
would repeat a request. This wording effectively requires that an
implementation of a responder ignore such duplicate requests. The
exception is for INTERNAL_IP4/6_ADDRESS, where the number of times the
request is repeated indicates the number of addresses requested to be
allocated.

In any case, the syntactical clumsiness is not limited to
INTERNAL_IP4/6_SUBNET, but also applies to INTERNAL_IP4/6_DNS/NBNS/DHCP,
and if we were to change it in one place we should change it in all.

But I'm not convinced a change is needed.

Do you still think so?

	--Charlie

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Friday, February 18, 2005 11:34 AM
To: [email-masked]; Charlie Kaufman
Cc: [email-masked]
Subject: Re: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes

[email-masked] wrote:
> In draft-eronen-ipsec-ikev2-clarifications-00 my preliminary
> conclusion was that the INTERNAL_IP4/6_SUBNET attributes do 
> not make sense in CFG_REQUESTs. 

hmm.. but what if the initiator does not want to know about
the prefixes?

IMO, the initiator should include the INTERNAL_IP6_SUBNET
attribute in CFG_REQUEST and the responder should just send
information on all prefixes.

> If the responder wants to send one or more INTERNAL_IP4/6_SUBNET
> attributes, it should do so, regardless of whether the initiator 
> asked for them or not (the initiator will ignore them if it has 
> no use for them). This case is also shown in the example in 
> Section 2.19.

okay.

> (It looks like the sentence "Multiple sub-networks MAY be
> requested" was copied verbatim from the MODE-CFG draft from
> 1999, but no longer makes sense. Or at least that's my
> current interpretation -- other comments are certainly welcome.)

should this be fixed during AUTH48 edits?

we just need to remove "Multiple sub-networks MAY be requested."
and say the responder always sends information on all prefixes?

Charlie?

Vijay

> 
> Best regards,
> Pasi
> 
> 
>>-----Original Message-----
>>From: Vijay Devarapalli
>>Sent: Thursday, February 17, 2005 10:32 PM
>>To: [email-masked]
>>Subject: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes
>>
>>
>>hi all,
>>
>>how does the initiator ask for information on multiple IPv6 
>>prefixes by using the INTERNAL_IP6_SUBNET attribute?
>>
>>section 3.15.1 says
>>
>>       o  INTERNAL_IP6_SUBNET - The protected sub-networks that
>>          this edge-device protects.  This 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].  Multiple sub-networks MAY be requested.  
>>          The responder MAY respond with zero or more sub-network 
>>          attributes.
>>
>>the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4
>>+ 17 for value) octets. I guess the responder could send
>>information about multiple IPv6 prefixes by including multiple
>>INTERNAL_IP6_SUBNET attributes in the the CFG_REPLY
>>payload. but how does the initiator indicate whether it wants
>>information about one IPv6 prefix or all the IPv6 prefixes? or
>>the does the responder by default send information about all
>>the IPv6 prefixes?
>>
>>Vijay
> 
> 
> 
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 18 Feb 2005 14:15:22 -0800

> even if only one is requested. 

regarding INTERNAL_IP64/6_SUBNET, the problem comes when the initiator 
does not know for sure if the responder sent information about all 
subnets, or just one subnet or a subset of the subnets.

I agree it does not make sense for the initiator to repeat an attribute
in the CFG_REQUEST (with the exception of INTERNAL_IP4/6_ADDR). infact
the initiator would not know how many times to repeat the attribute
because it would not know how many subnets/DNS servers/DHCP servers are 
available. :)

> I can think of no reason why someone

> But I'm not convinced a change is needed.

well, if not this document, we need to document this somewhere. I am
sure someone will come across this later and have the same question
I had.

we could just remove the text which says multiple sub-networks may be
requested. and let the text about the responder replying with one or 
more attributes as it is.

Vijay