Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 1 Dec 2009 08:31:29 -0800

Dave Craig wrote:
> Laganier, Julien wrote:
> > Dave Craig wrote:
> >>
> >> [...]
> >>
> >> 3.1. page 6, How about adding the following to the end of the SPI
> >> field descriptions (EF), "A present SPI field does not match traffic
> >> without an IPsec header."  Also applies to 3.2. page 10.
> >
> > Would it be simpler to say "this field MUST NOT be present if the
> > protocol is neither IPsec AH nor ESP"?
> 
> Both solutions would work, but is there a reason to add more
> verification logic and possible causes for failure messages in the
> protocol?

Let me illustrate in terms of dealing with ports in RFC 4306, which I was trying to mimic with our traffic selector format: RFC 4306 specify that the start and end port MUST be respectively set to 0 and 65535 for protocols for which port is undefined. So the port fields are there but they MUST be explicitly marked as 'irrelevant' with these special values. Since we have the ability to omit the values that seemed a straightforward way to signal that these fields are 'irrelevant'.

On the other hand your proposal implies that the presence of SPI field matches against the protocol field that has to be IPsec AH or ESP, so this seems redundant. It also introduces some ambiguities: what do I do if I match packet that has no SPI but has port numbers, and the traffic selector has both ports and SPIs. Does it match or not?
 
> >> 3.1. page 7, How about adding the following to the end of the port
> >> field description (GHIJ), "A present port field does not match
> >> traffic with IP protocols that do not define a transport port."  
> >> Also add a reference to the port number definitions, so it is not ambiguous
> >> which port you're talking about.
> >> http://www.iana.org/assignments/port-numbers.
> >
> > I am not sure we want to cite the port-numbers registry. This seems
> > to imply that only the ports as registered in the registry are legal in
> > terms of this specification, and I'm not sure we want that...
> >
> > As to restricting the port field to protocols defining a transport
> > port, I'm wondering whether we want to have a provision similar to that
> > of RFC 4306 (IKEv2) w.r.t. ICMP:
> >
> >   For the ICMP protocol, the two one-octet fields Type and Code are
> >   treated as a single 16-bit integer (with Type in the most significant
> >   eight bits and Code in the least significant eight bits) port number 
> >   for the purposes of filtering based on this field.
> 
> Which fields would you use for a GRE packet when the filter only
> specifies ports?  Suggest paring down the problem to match only
> specified protocol where you know the mapping, then.  IPv6 NH also
> matches ICMPv6 type+code.  IPv4 protocol also matches ICMP type +
> code.

As above for handling SPIs in protocols which don't have them, I would suggest to say "this field MUST NOT be present if the protocol does not have protocol numbers, or is neither ICMP nor ICMPv6".

--julien

---

From: Dave Craig <[email-masked]>
Date: Tue, 1 Dec 2009 11:13:02 -0800

> As above for handling SPIs in protocols which don't have them, I would suggest to say "this field MUST NOT be present if the protocol does not have protocol numbers, or is neither ICMP nor ICMPv6".

I see the advantage of being more pedantic in message handling.  The
only downside is that the spec will need a lot more text explaining
all of the possible error scenarios.  It is not just a matter of
having SPIs present without specifying IPsec protocol.  Each field
needs an enumeration of the protocols that it is valid for.
Implementers also will need to add more verification logic to provide
this validation.

I would still like to advocate leaving the mappings implicit like
firewalls often do today.  When I specify only a port number in the
filter, the implementation makes a best effort mapping to what that
means for each protocol or does not match the packet when it does not
make sense to do the mapping.

Thanks,
Dave

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 1 Dec 2009 11:28:36 -0800

Dave Craig wrote: 
> On Tue, Dec 1, 2009 at 8:31 AM, Laganier, Julien <[email-masked]>
> > [...]
> >
> > As above for handling SPIs in protocols which don't have them, I
> > would suggest to say "this field MUST NOT be present if the protocol
> > does not have protocol numbers, or is neither ICMP nor ICMPv6".
> >
> > --julien
> 

Ok, I understand your point. I don't have a strong opinion on the matter, so if nobody else has one, I'd suggest that we move forward with your original proposal (i.e., "A present port field does not match traffic with IP protocols that do not define a transport port " and "A present SPI field does not match traffic without an IPsec header".)

--julien

---

From: "Yuri Ismailov" <[email-masked]>
Date: Thu, 3 Dec 2009 09:51:34 +0100

Hello,

I think this sounds reasonable, at least unambiguous.
I have another ambiguity concern regarding IPv6 traffic selector.
The last two fields specify "next header" range. However, an IPv6 packet
may contain optional headers following right after the IPv6 header.
It means that the value of NH is not necessarily transport protocol
value.
Then the question is will the port numbers be ignored in such case?
As I understand it yes, according to the previous discussion.

This will lead to the result the the packet will not match the traffic
selector
Is that correct?

Regards
Yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laganier, Julien
Sent: Tuesday, December 01, 2009 8:29 PM
To: Dave Craig
Cc: [email-masked]; [email-masked]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01

> make sense to do the mapping.

Ok, I understand your point. I don't have a strong opinion on the
matter, so if nobody else has one, I'd suggest that we move forward with
your original proposal (i.e., "A present port field does not match
traffic with IP protocols that do not define a transport port " and "A
present SPI field does not match traffic without an IPsec header".)

--julien
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 Dec 2009 11:46:04 +0200

Folks, thanks for the reviews and discussion on this draft. I was out
of the office this week and I am traveling on business during the next
but I will try to catch up as soon as I can.

Thanks
George

On 11/18/09, Laganier, Julien <[email-masked]> wrote:
> Folks,
>
> As stated during the meeting, we're starting a two weeks WGLC on our
> "Traffic Selectors for Flow Bindings" document, available at the following
> URL:
>
> <http://tools.ietf.org/wg/mext/draft-ietf-mext-binary-ts-01>
>
> Please review the specification, post your comments to the mailing list, and
> state whether or not you think the document is ready to be forwarded to IESG
> before 2009-12-02 6:00PM PST.
>
> Thank you for your support.
>
> --julien & marcelo, MEXT chairs

---

From: "Stupar, Patrick" <[email-masked]>
Date: Thu, 10 Dec 2009 08:39:54 -0800

Hi all,

I reviewed the draft (I hope I am not too late). Overall I think that the draft is in good shape and can be progressed.  Here are my comments:

The content of the draft needs to be aligned with the Traffic Selector sub-option defined in draft-ietf-mext-flow-binding-04. This implies the following:

-Section 3 title should not contain the word sub-options (this draft defines a TS format not a sub-option)

-Section 3

	"The following values of the sub-option Type field, are reserved in
	   this specification for binary traffic selectors"

	s/sub-option Type/ Traffic selector Format

-Section 3.1

	"   If the Type field of the traffic selector sub-option indicates "IPv4
	   binary traffic selector",... "

	s/Type / TS Format

	The format of the IPv4 traffic selector needs to be updated accordingly with  draft-ietf-mext-flow-binding-04

-Section 3.2

	"   If the Type field of the traffic selector sub-option indicates "IPv6
	   binary traffic selector", then the traffic selector is formatted as
	   follows:"

	s/Type / TS Format

	The format of the IPv6 traffic selector needs to be updated accordingly with  draft-ietf-mext-flow-binding-04

I also have a question for my understanding: in the definition of Start Destination address (C) for both IPv4 and IPv6 formats there is the following sentence:
	" In other words this (i.e. the destination address) is one of the
	  registered addresses of the mobile node."
	
My understanding was that this field should contain the mobile node Home Address. From 3775 my understanding is that the primary CoA is the registered address. What am I missing?

Regards,

Patrick

> Sent: Wednesday, November 18, 2009 4:57 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01
> 
> Folks,
> 
> "Traffic Selectors for Flow Bindings" document, available at the
> following URL:
> 
> Please review the specification, post your comments to the mailing
> list, and state whether or not you think the document is ready to be
> forwarded to IESG before 2009-12-02 6:00PM PST.
>

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 Dec 2009 11:36:26 +0000

Thanks Ben,

All comments taken into account.

George

On Mon, Nov 30, 2009 at 6:03 AM, Benjamin Lim
<[email-masked]> wrote:
> Hi,
>
> I have reviewed the draft and have some questions/editorials stated below.
>
> Regards,
> Benjamin Lim
>
> -----------
>> Abstract
>>
>> This document defines binary formats for IPv4 and IPv6 traffic
>> selectors to be used in conjuction with flow bindings for Mobile
> [Ben] s/ conjuction/ conjunction
>

OK

>> IPv6.
>
> ...
>
>> 2.  Introduction
>>
>> This document defines binary formats for IPv4 and IPv6 Traffic
>> Selector sub-options as defined in [I-D.ietf-mext-flow-binding].
>>
>> The binary traffic selector sub-options defined here, allow efficient
>>  identification of flow(s) based on well known fields in IPv4
>> [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP
>> [RFC0793] and UDP [RFC0768].
>
> [Ben] Propose to rephrase to "The binary traffic selector sub-options
> defined here, allow for efficient..."
>

OK

> ...
>
>> 3.1.  IPv4 binary traffic selector
>
> ...
>
>>
>> (B)End Source Address
>>
>> If more than one contiguous source addresses need to be mached
> [Ben] s/ mached/ matched
>

OK

>> then this field can be used to indicate the end value of a range
>> starting from the value of the Start Source Address field.  This
>> field MUST NOT be included unless the Start Source Address field is
>> included.  When this field is included the receiver will match all of
>> the addresses between fields (A) and (B), inclusive of (A) and (B).
>
> [Ben] For clarification, if it is only to match one IP address of CN,
> does it mean that "(A)Start Source Address" and "(B)End Source Address"
> would be of the same IP address? The same question applies to those
> fields that allow specifying ranges.
>
> ...

GT> Yes, all of the "End" definitions start with "If more than one ..."

>>
>> (D)End Destination Address
>>
>> If more than one contiguous destination addresses need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a
>> range starting from the value of the Start Destination Address field.
>> This field MUST NOT be included unless the Start Destination Address
>> field is included.  When this field is included the receiver will
>> match all of the addresses between fields (C) and (D), inclusive of
>> (C) and (D).
>
> ...
>
>> (F)End SPI - Security Parameter Index
>>
>> If more than one contiguous SPI values need to be mached then this
> [Ben] s/ mached/ matched
>
>> field can be used to indicate the end value of a range starting from
>> the value of the Start SPI field.  This field MUST NOT be included
>> unless the Start SPI field is included.  When this field is included
>> the receiver will match all of the SPI values between fields (E) and
>> (F), inclusive of (E) and (F).
>
> ...
>
>> (H)End Source Port
>>
>> If more than one contiguous source port numbers need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a range
>> starting from the value of the Start Source Port field.  This field
>> MUST NOT be included unless the Start Source Port field is included.
>> When this field is included the receiver will match all of the port
>> numbers between fields (G) and (H), inclusive of (G) and (H).
>
> ...
>
>> (J)End Destination Port
>>
>> If more than one contiguous destination port numbers need to be
>> mached then this field can be used to indicate the end value of a
> [Ben] s/ mached/ matched
>
>> range starting from the value of the Start Destination Port field.
>> This field MUST NOT be included unless the Start Destination Port
>> field is included.  When this field is included the receiver will
>> match all of the port numbers between fields (I) and (K),
> [Ben] s/ (K)/ (J)
>
>> inclusive of (I) and (J).
>>
>> (K)Start DS - Differential Services
>>
>> This field identifies the first differential services value, from the
>> range of differential services values to be matched, on data packets
>> as seen by the home agent.  Note that this field is called Type of
>> Service field in [RFC0791].  [RFC3260] then clarified that the field
>> has been redefined as 6 bits DS field and 2 bits reserved, later
>> claimed by Explicit Congestion Notification (ECN) [RFC3168].  For the
>> purpose of this specification the DS field is 8bit long, were the 6
> [Ben] s/ 8bit/ 8 bits
>
>> most significant bits indicating the DS
>> field to be matched and the 2 list significant bits MUST be set to 0
>> by the sender and ignored by the receiver.
>>
>> (L)End DS - Differential Services
>>
>> If more than one contiguous DS values need to be mached then this
> [Ben] s/ mached/ matched
>
>> field can be used to indicate the end value of a range starting from
>> the value of the Start DS field.  This field MUST NOT be included
>> unless the Start DS field is included.  When this field is included
>> the receiver will match all of the values between fields (K) and (L),
>> inclusive of (K) and (L).
>
> [Ben] I assume that same note for (K) on how to format the bits in the
> DS field applies to (L) also? I.e. For the purpose of this specification
> the DS field is 8 bits long, were the 6 most significant bits indicating
> the DS field to be matched and the 2 list significant bits MUST be set
> to 0 by the sender and ignored by the receiver.
>

GT> Yes

> ...
>
>> (N)End Protocol
>>
>> If more than one contiguous protocol values need to be mached then
> [Ben] s/ mached/ matched
>
>> this field can be used to indicate the end value of a range starting
>> from the value of the Start Protocol field.  This field MUST NOT be
>> included unless the Start Protocol field is included. When this field
>> is included the receiver will match all of the values between fields
>> (M) and (N), inclusive of (M) and (N).
>
> [Ben] For my understanding, can I ask what is the purpose of the
> "Protocol field"?
>

GT> The Protocol field in the IPv4 header defines the next header
e.g., UDP/TCP etc

> ...
>
>> 3.2.  IPv6 binary traffic selector
>
> ...
>
>> (B)End Source Address
>>
>> If more than one contiguous source addresses need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a range
>> starting from the value of the Start Source Address field.  This
>> field MUST NOT be included unless the Start Source Address field is
>> included.  When this field is included the receiver will match all of
>> the addresses between fields (A) and (B), inclusive of (A) and (B).
>
> ...
>
>> (D)End Destination Address
>>
>> If more than one contiguous destination addresses need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a
>> range starting from the value of the Start Destination Address field.
>> This field MUST NOT be included unless the Start Destination Address
>> field is included.  When this field is included the receiver will
>> match all of the addresses between fields (C) and (D), inclusive of
>> (C) and (D).
>
> ...
>
>> (F)End SPI - Security Parameter Index
>>
>> If more than one contiguous SPI values need to be mached then this
> [Ben] s/ mached/ matched
>
>> field can be used to indicate the end value of a range starting from
>> the value of the Start SPI field.  This field MUST NOT be included
>> unless the Start SPI field is included.  When this field is included
>> the receiver will match all of the SPI values between fields (E) and
>> (F), inclusive of (E) and (F).
>
> ...
>
>> (G)Start Flow Label
>>
>> This field identifies the first flow label value, from the range of
>> flow label values to be matched, on data packets as seen by the home
>> agent.  According to [RFC2460] the flow label is 24-bit long. For the
>> purpose of this specification the sender of this options MUST prefix
>> flow label values with 8-bits of "0" before inserting it in this
>> field.
> [Ben] Reword the above sentence to "For the purpose of this
> specification the sender of this option MUST prefix the flow label
> values with 8-bits of "0" before inserting it into this field."
>
>> The receive SHOULD ignore the first 8-bits of
> [Ben] s/ receive/ receiver
>
>> this field.
>>
>> (H)End Flow Label
>>
>> If more than one contiguous flow label values need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a range
>> starting from the value of the Start Flow Label field.  This field
>> MUST NOT be included unless the Start Flow Label field is included.
>> When this field is included the receiver will match all of the flow
>> label values between fields (G) and (H), inclusive of (G) and (H).
>
> ...
>
>> (J)End Source Port
>>
>> If more than one contiguous source port numbers need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a range
>> starting from the value of the Start Source Port field.  This field
>> MUST NOT be included unless the Start Source Port field is included.
>> When this field is included the receiver will match all of the port
>> numbers between fields (I) and (J), inclusive of (I) and (J).
>
> ...
>
>> (L)End Destination Port
>>
>> If more than one contiguous destination port numbers need to be
>> mached then this field can be used to indicate the end value of a
> [Ben] s/ mached/ matched
>
>> range starting from the value of the Start Destination Port field.
>> This field MUST NOT be included unless the Start Destination Port
>> field is included.  When this field is included the receiver will
>> match all of the port numbers between fields (K) and (L), inclusive
>> of (K) and (L).
>>
>> (M)Start DS - Differential Services
>>
>> This field identifies the first differential services value, from the
>> range of differential services values to be matched, on data packets
>> as seen by the home agent.  Note that this field is called Type of
>> Service field in [RFC0791].  [RFC3260] then clarified that the field
>> has been redefined as 6 bits DS field and 2 bits reserved, later
>> claimed by Explicit Congestion Notification (ECN) [RFC3168].  For the
>> purpose of this specification the DS field is 8bit long, were the 6
> [Ben] s/ 8bit/ 8 bits
>
>> most significant bits indicating the DS
>> field to be matched and the 2 list significant bits MUST be set to 0
>> by the sender and ignored by the receiver.
>>
>> (N)End DS - Differential Services
>>
>> If more than one contiguous DS values need to be mached then this
> [Ben] s/ mached/ matched
>
>> field can be used to indicate the end value of a range starting from
>> the value of the Start DS field.  This field MUST NOT be included
>> unless the Start DS field is included.  When this field is included
>> the receiver will match all of the values between fields (M) and (N),
>> inclusive of (M) and (N).
>
> [Ben] I assume that same note for (M) on how to format the bits in the
> DS field applies to (N) also? I.e. For the purpose of this specification
> the DS field is 8 bits long, were the 6 most significant bits indicating
> the DS field to be matched and the 2 list significant bits MUST be set
> to 0 by the sender and ignored by the receiver.
>
> ...
>
>> (P)End NH - Next Header
>>
>> If more than one contiguous next header values need to be mached
> [Ben] s/ mached/ matched
>
>> then this field can be used to indicate the end value of a range
>> starting from the value of the Start NH field.  This field MUST NOT
>> be included unless the Start next header field is included. When this
>> field is included the receiver will match all of the values between
>> fields (O) and (P), inclusive of (O) and (P).
>
> ...
>
>> 4.  Security Considerations
>>
>> This draft defines the format of traffic selector sub-options defined
>>  in the flow bindings [I-D.ietf-mext-flow-binding].  The authors have
>>  not identified any security concenrs pertaining to this draft beyond
> [Ben] s/ concenrs/ concerns
>
>> what is already identified in [I-D.ietf-mext-flow-binding].
>
> ...
>
>> 6.  Aknowledgements
> [Ben] s/ Aknowledgements/ Acknowledgements
>
>>
>> The authors would like to thank Patrick Stupar and Julien Laganier
>> for their contributions to this document.

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 Dec 2009 11:45:09 +0000

Julien, thanks for the review...comments inline...

On Mon, Nov 30, 2009 at 9:44 PM, Laganier, Julien <[email-masked]> wrote:
> Folks -
>
> This is my hat-less draft review:
>
> I think the draft is ready provided that the minor points below are addressed:
>
> 1- We should include the following alignments requirements for the sub-options:
>
> * IPv4 TS:
> - 4n aligned if A, B, C, D, E or F is set
> - 2n aligned if G, H, I or J is set
> - n aligned otherwise
>
> * IPv6 TS:
> - 8n aligned if A, B, C, or D is set
> - 4n aligned if E, F, G, or H is set
> - 2n aligned if I, J, K, or L is set
> - n aligned otherwise
>

GT> Thanks Julien, I added these.

> 2- I feel that the text describing the Start/End field for ranges could be made simpler by formulating a la RFC 4306 (IKEv2), as per this template:
>
> * Start <Xyz>(<v>) - Value specifying the smallest <Xyz>
>      allowed by this Traffic Selector. If the End <Xyz> field
>      is not included, this is the only <Xyz> allowed by this
>      Traffic Selector.
>
> * End <Xyz>(<w>) - Value specifying the largest <Xyz>
>      allowed by this Traffic Selector. This field MUST NOT
>      be included unless the Start <Xyz> field is included.
>

GT> Julien, I would like to avoid unnecessary re-writes. I do not
think this text is "simpler" and I do not think the existing text is
"unclear" :-)

>> Please review the specification, post your comments to the mailing list,
>> and state whether or not you think the document is ready to be

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 Dec 2009 11:54:03 +0000

Patrick,

I accepted all your comments, thanks..
WRT to your last question regarding "registered addresses" I will
clarify this as "registered home addresses" ... I say registered
because it could be one of the NEMO addresses that are registered
separately from the home address.

George

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 Dec 2009 12:15:17 +0000

Thanks Dave,

comments inline...

On Tue, Dec 1, 2009 at 12:48 AM, Dave Craig <[email-masked]> wrote:
> 3. page 5.  How about specifying 0x1 for IPv4 traffic selector and 0x2
> for IPv6 traffic selector?
>

GT> If I am not mistaken IANA does this when this is converted to RFC

> without an IPsec header."  Also applies to 3.2. page 10.

GT> of course, and a UDP port does not match anything without a UDP
transport header....too obvious.

> field description (GHIJ), "A present port field does not match traffic
> with IP protocols that do not define a transport port."  Also add a
> reference to the port number definitions, so it is not ambiguous which
> port you're talking about.

GT> Added a pointer to IANA page.

> 3.2. page 12 (OP), Suggest making the next header match against any of
> the IPv6 next headers.  This would enable a filter to match against a
> jumbo payload that might be behind a router alert.  New text might
> read, "This field identifies the first 8-bit next header value" of any
> of the next headers in the packet, "from the..."
>
>

GT> We are not supposed to be doing recursive searches....we are just
looking at IP header and Transport header....that's it. This is the
directive we got from the chairs as well as the IESG....i.e., keep
this simple while we gather implementation experience and only
complicate things further based on specific needs from deployments.

> 3.2.
>
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    Reserved     |             (G)Start Flow Label             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    Reserved     |             (H)End Flow Label               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> probably should update the block for DS, too.
>

GT> This is how it was earlier but this gets really confusing unless
you are assign flags to the Reserved fields. The description of the
fields clearly indicates that Flow labels are prefixed with 8bits of
"0" to result in the same thing.

> 3.2.
>
> For the purpose of this specification, the sender of this option
>      MUST prefix flow label values with 8-bits of "0" before inserting
>      it in this field.
>
>
> s/mached/matched/
>
> s/2 list significant/2 least significant/
>
> 3.2(M) /3.1(K)
>
> For the purpose of this specification the DS field is
>      8 bits long, where the 6 most...
>
>
>
> Hope this helps,
> Dave
>
>
> On Wed, Nov 18, 2009 at 7:56 AM, Laganier, Julien <[email-masked]> wrote:
>> Folks,
>>
>> As stated during the meeting, we're starting a two weeks WGLC on our "Traffic Selectors for Flow Bindings" document, available at the following URL:
>>
>> Please review the specification, post your comments to the mailing list, and state whether or not you think the document is ready to be forwarded to IESG before 2009-12-02 6:00PM PST.
>>

---

From: Benjamin Lim <[email-masked]>
Date: Wed, 16 Dec 2009 09:14:43 +0800

Hi Patrick, George,

Should not the registered address take into account care-of addresses? I
assume the binary traffic selector can be applied on correspondent node
with RO enabled right?

Also another question from me. If the mobile node is assigned a home
IPv6 prefix rather than a home IPv6 address, for the IPv6 binary traffic
selector, does the mobile node fills in fields (C) Start Destination
Address and (D) End Destination Address as:

1) (C) = first address of the home prefix; (D) = last address of the
home prefix. or
2) (C) = home prefix

Regards,
Benjamin Lim

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 16 Dec 2009 10:33:49 +0000

> assume the binary traffic selector can be applied on correspondent node

GT> Since we allow the MN to indicate matching source and destination
addresses, we cover the case where CoAs need to be matched.

> 1) (C) = first address of the home prefix; (D) = last address of the

GT> It is (1) since these fields are defined as 128bit addresses, not
prefixes+length.