Subject: Re: [savi] about draft-ietf-savi-fcfs-02

From: zhengruobin 35664 <[email-masked]>
Date: Tue, 01 Dec 2009 17:49:47 +0800

Hi marcelo,

BRAS is the abbreviation of Broadband Remote Access Server, which is defined by DSL Forum in TR101.

In the IPv4 access network, the bindings of IPv6 address and a port are done by DHCPv4 snooping. But in the IPv6 access network, the SLAAC may be used insteads of DHCPv6 for IPv6 address assignment. Thus, in case of SLAAC, a mechanism to discover the bindings of IPv6 address and a port is needed.

Robin

----- 原邮件 -----
发件人: marcelo bagnulo braun <[email-masked]>
日期: 星期六, 十一月 28日, 2009 下午4:27
主题: Re: [savi] about draft-ietf-savi-fcfs-02
收件人: robin <[email-masked]>
抄送: [email-masked]

> robin escribió:
> > Hi marcelo,
> > In IPv4 world, there is a binding of IPv4 address and port in 
> BRAS 
> 
> what is bras?
> 
> > for the
> > sake of security. When migration to IPv6, we do need a method to 
> bind the
> > IPv6 address and its corresponding port. 
> > The optimization defined by the MAY in draft-ietf-savi-fcfs-01 
> provided a
> > practical solution for this. 
> >
> >   
> i am not sure i follow (fwiwi i am not oposing to this, i simply 
> fail to 
> understnad what you are saying)
> even without this optimization, we can create a binding for any 
> IPv6 
> address and a port, so i am not sure i understnad what is your point.
> 
> 
> The only potential issue that i understnad this optimization is 
> addressing, is the case of legacy implementations, that follow 
> 2462 
> instead of 4862 that may not do the DAD for the global address if 
> they 
> have done so for the corresponding link local.
> 
> Regards, marcelo
> 
> 
> 
> > Best Regards,
> >
> > Robin
> >
> > -----Original Message-----
> > From: marcelo bagnulo braun [mailto:[email-masked]] 
> > Sent: Friday, November 27, 2009 3:26 PM
> > To: zhengruobin 35664
> > Cc: [email-masked]
> > Subject: Re: [savi] about draft-ietf-savi-fcfs-02
> >
> > zhengruobin 35664 escribió:
> >   
> >> Hi There,
> >>
> >> In the draft-ietf-savi-fcfs-01, there is a description as 
> follows in
> >>     
> > 3.2.2.  Processing of control packets of draft-ietf-savi-fcfs-01:
> >   
> >> "If no NADV message for that Target Address is received in
> >>          DADTimeout, then the status of the entry is change to 
> valid and
> >>          the lifetime of the entry is set to LIFETIME.  In 
> addition, if
> >>          the address contained in the newly created entry is a link
> >>          local address, FCFS SAVI MAY as well create entries 
> for the
> >>          global addresses resulting from concatenating the 
> Interface>>          Identifier of the link local address and the 
> global prefixes
> >>          contained in the Prefix List for the Interface through 
> which>>          the NSOL message was received."
> >>
> >> But the above is not covered in the draft-ietf-savi-fcfs-02. I 
> wonder what
> >>     
> > happened to this.
> >   
> >>   
> >>     
> >
> > i understand you are talking about the optimization defined by 
> the MAY, 
> > right?
> > since the version 01 has been through a major rewriting, this 
> was 
> > dropped unitentionally.
> >
> > I will include it in the next version if people still think it 
> is a good 
> > idea
> >
> > regards, marcelo
> >
> >
> >
> >   
> >> Best regards,
> >>
> >> Robin
> >>
> >>
> >> _______________________________________________
> >> savi mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/savi
> >>
> >>   
> >>     
> >
> >
> >   
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Dec 2009 10:59:35 +0100

> In the IPv4 access network, the bindings of IPv6 address and a port are done by DHCPv4 snooping. But in the IPv6 access network, the SLAAC may be used insteads of DHCPv6 for IPv6 address assignment…
make sense
AFIAU, this is covered int he new version of the draft... what do you
think it is missing?

I mean, the particular text you are pointing out was an optimization for
the in order to automatically create the binding for the gloabl
addresses once the binding for the local address has been created. I
don't have any problem with that optimization, but i think it changes
much the resulting baheviour.

So, i am not sure what do you think it is missing in order to support
the case you describe.

Regards, marcelo

---

From: zhengruobin 35664 <[email-masked]>
Date: Tue, 01 Dec 2009 18:53:08 +0800

Hi Marcelo,

 In the draft-ietf-savi-fcfs-01, it proposes " if the address contained in the newly created entry is a link
local address, FCFS SAVI MAY as well create entries for the global addresses resulting from concatenating the 
Interface Identifier of the link local address and the global prefixes contained in the Prefix List for the Interface through 
which the NSOL message was received." However, this is missing in draft-ietf-savi-fcfs-02.

I don't know what was the original purpose of this optimization for addressing. But it seems to me that it may be used to discover the user's global address by SAVI device in case of SLAAC. 

Best regards,

Robin

----- 原邮件 -----
发件人: marcelo bagnulo braun <[email-masked]>
日期: 星期二, 十二月 1日, 2009 下午6:29
主题: Re: [savi] about draft-ietf-savi-fcfs-02
收件人: zhengruobin 35664 <[email-masked]>
抄送: [email-masked]

> > In the IPv4 access network, the bindings of IPv6 address and a 
> port are done by DHCPv4 snooping. But in the IPv6 access network, 
> the SLAAC may be used insteads of DHCPv6 for IPv6 address 
> assignment. Thus, in case of SLAAC, a mechanism to discover the 
> bindings of IPv6 address and a port is needed.
> >
> >   
> make sense
> >> address and a port, so i am not sure i understnad what is your 
> point.>>
> >>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Dec 2009 12:06:44 +0100

> I don't know what was the original purpose of this optimization for addressing. But it seems to me that it may be used to discover the user's global address by SAVI device in case of SLAAC. 
But the node will do a DAD for the gloabl address as well, right? so the
savi device will learn it when that happens, right?

That is why i said it is an optimization.
What am i missing?

regards, marcelo

>>> BRAS is the abbreviation of Broadband Remote Access Server, 
>>>       
>> which is defined by DSL Forum in TR101.
>>     
>>>>> sake of security. When migration to IPv6, we do need a method 
>>>>>           
>> to 
>>     
>>>>>       
>>>>>           
>>>> bind the
>>>>     
>>>>         
>>>> i am not sure i follow (fwiwi i am not oposing to this, i 
>>>>         
>> simply 
>>     
>>>> fail to 
>>>> instead of 4862 that may not do the DAD for the global address 
>>>>         
>> if 
>>     
>>>> they 
>>>>>>          DADTimeout, then the status of the entry is change 
>>>>>>             
>> to 
>>     
>>>>>>         
>>>>>>             
>>>> valid and
>>>>     
>>>>         
>>>>>>          the address contained in the newly created entry is 
>>>>>>             
>> a link
>>     
>>>> Interface>>          Identifier of the link local address and 
>>>>         
>> the 
>>     
>>>> global prefixes
>>>>     
>>>>         
>>>>>>          contained in the Prefix List for the Interface 
>>>>>>             
>> through 
>>     
>>>>>>         
>>>>>>             
>>>>>> But the above is not covered in the draft-ietf-savi-fcfs-02. 
>>>>>>             
>> I 
>>     
>>>>>>         
>>>>>>             
>>>> wonder what
>>>>     
>>>>         
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> happened to this.
>>>>>   
>>>>>       
>>>>>           
>>>>>>   
>>>>>>     
>>>>>>         
>>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Dec 2009 12:34:36 +0100

(mm, it seems the savi cc got lost somehwere. i include it back)

zhengruobin 35664 escribió:
> Hi Marcelo,
>
> A DAD for a LLA is mandatory. But a DAD for a global address is not mandatory. 
> How about in case of only DAD for a LLA?
>
>   
right, this is what i was mentioning earlier.

This has changed from rfc2462 to rfc4862

In rfc2462, this was accepted.

in rfc4862, the rfc reads:

5.4. Duplicate Address Detection

Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions:

- An interface whose DupAddrDetectTransmits variable is set to zero
does not perform Duplicate Address Detection.

- Duplicate Address Detection MUST NOT be performed on anycast
addresses (note that anycast addresses cannot syntactically be
distinguished from unicast addresses).

- Each individual unicast address SHOULD be tested for uniqueness.
Note that there are implementations deployed that only perform
Duplicate Address Detection for the link-local address and skip
the test for the global address that uses the same interface
identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of
"optimization" is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization.

So, this is not reccomended i.e. if you do that and something breaks,
then it is your problem.

So the question is whether we want to account for these type of hosts or
not.

As i mentioned earlier, i don't have a problem with doing that. I would
be interested in hearing what other people have to say about this.

Regards, marcelo

> 日期: 星期二, 十二月 1日, 2009 下午7:07
>>>  In the draft-ietf-savi-fcfs-01, it proposes " if the address 
>>>       
>> contained in the newly created entry is a link
>>     
>>> local address, FCFS SAVI MAY as well create entries for the 
>>>       
>>> Interface Identifier of the link local address and the global 
>>>       
>> prefixes contained in the Prefix List for the Interface through 
>>     
>>> which the NSOL message was received." However, this is missing 
>>>       
>> in draft-ietf-savi-fcfs-02.
>>     
>>> I don't know what was the original purpose of this optimization 
>>>       
>> for addressing. But it seems to me that it may be used to discover 
>> the user's global address by SAVI device in case of SLAAC. 
>>     
>>>   
>>>       
>>>> port are done by DHCPv4 snooping. But in the IPv6 access 
>>>>         
>> network, 
>>     
>>>> AFIAU, this is covered int he new version of the draft... what 
>>>>         
>> do you
>>     
>>>> think it is missing?
>>>>
>>>> addresses once the binding for the local address has been 
>>>>         
>> created. I
>>     
>>>> don't have any problem with that optimization, but i think it 
>>>>         
>> changes>> much the resulting baheviour.
>>     
>>>> So, i am not sure what do you think it is missing in order to 
>>>>         
>> support>> the case you describe.
>>     
>>>> Regards, marcelo
>>>>
>>>>     
>>>>         
>>>>> Robin
>>>>>
>>>>> ----- 原邮件 -----
>>>>>>> In IPv4 world, there is a binding of IPv4 address and port 
>>>>>>>               
>> in 
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> BRAS 
>>>>>>
>>>>>> what is bras?
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> for the
>>>>>>> sake of security. When migration to IPv6, we do need a 
>>>>>>>               
>> method 
>>     
>>>>>>>           
>>>>>>>               
>>>> to 
>>>>     
>>>>         
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> bind the
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> The optimization defined by the MAY in draft-ietf-savi-fcfs-
>>>>>>>               
>> 01 
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> provided a
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>> even without this optimization, we can create a binding for 
>>>>>>             
>> any 
>>     
>>>>>> IPv6 
>>>>>> address and a port, so i am not sure i understnad what is 
>>>>>>             
>> your 
>>     
>>>>>>         
>>>>>>             
>>>> point.>>
>>>>     
>>>>         
>>>>>> The only potential issue that i understnad this optimization 
>>>>>>             
>> is 
>>     
>>>>>> addressing, is the case of legacy implementations, that 
>>>>>>             
>> follow 
>>     
>>>>>> 2462 
>>>>>> instead of 4862 that may not do the DAD for the global 
>>>>>>             
>> address 
>>     
>>>>>>         
>>>>>>             
>>>> if 
>>>>     
>>>>         
>>>>>> they 
>>>>>>> 3.2.2.  Processing of control packets of draft-ietf-savi-
>>>>>>>               
>> fcfs-01:
>>     
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>>          the address contained in the newly created entry 
>>>>>>>>                 
>> is 
>>     
>>>>>>>>             
>>>>>>>>                 
>>>> a link
>>>>     
>>>>         
>>>>>>>>          local address, FCFS SAVI MAY as well create 
>>>>>>>>                 
>> entries 
>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>> for the
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>>> But the above is not covered in the draft-ietf-savi-fcfs-
>>>>>>>>                 
>> 02. 
>>     
>>>>>>>>             
>>>>>>>>                 
>>>> I 
>>>>     
>>>>         
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>> wonder what
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> happened to this.
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>>   
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> i understand you are talking about the optimization defined 
>>>>>>>               
>> by 
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> the MAY, 
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> right?
>>>>>>> since the version 01 has been through a major rewriting, 
>>>>>>>               
>> this 
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> was 
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> dropped unitentionally.
>>>>>>>
>>>>>>> I will include it in the next version if people still think 
>>>>>>>               
>> it 
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> is a good 
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> idea
>>>>>>>
>>>>>>> regards, marcelo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Robin
>>>>>>>>
>>>>>>>>

---

From: Alberto García <[email-masked]>
Date: Tue, 1 Dec 2009 15:51:51 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de marcelo
|  bagnulo braun
|  Enviado el: martes, 01 de diciembre de 2009 12:35
|  Para: zhengruobin 35664; SAVI Mailing List
|  Asunto: Re: [savi] about draft-ietf-savi-fcfs-02
|  
|  (mm, it seems the savi cc got lost somehwere. i include it back)
|  
|  zhengruobin 35664 escribió:
|  > Hi Marcelo,
|  >
|  > A DAD for a LLA is mandatory. But a DAD for a global address is not
|  mandatory.
|  > How about in case of only DAD for a LLA?

Even if hosts don't do DAD for global addresses and SAVI does not create a binding for the global address 'resulting' from the LLA when the LLA address does DAD, I don't see much problem.
(fcfs-v02): the reception of a data packet with the global address as source address when the SAVI device is in NO_BIND state triggers a 2xDAD_NSOL that is sent through the Trusted ports and moves to TENTATIVE. Unless there is a binding in other SAVI device and a host has the address configured, the timer expires and state moves to VALID. 

Any problem with this behavior? (apart from loosing - buffering - some data packets)

Regards,
Alberto

|  >
|  >
|  right, this is what i was mentioning earlier.
|  
|  This has changed from rfc2462 to rfc4862
|  
|  In rfc2462, this was accepted.
|  
|  in rfc4862, the rfc reads:
|  
|  5.4. Duplicate Address Detection
|  
|  
|  Duplicate Address Detection MUST be performed on all unicast
|  addresses prior to assigning them to an interface, regardless of
|  whether they are obtained through stateless autoconfiguration,
|  DHCPv6, or manual configuration, with the following exceptions:
|  
|  - An interface whose DupAddrDetectTransmits variable is set to zero
|  does not perform Duplicate Address Detection.
|  
|  - Duplicate Address Detection MUST NOT be performed on anycast
|  addresses (note that anycast addresses cannot syntactically be
|  distinguished from unicast addresses).
|  
|  - Each individual unicast address SHOULD be tested for uniqueness.
|  Note that there are implementations deployed that only perform
|  Duplicate Address Detection for the link-local address and skip
|  the test for the global address that uses the same interface
|  identifier as that of the link-local address. Whereas this
|  document does not invalidate such implementations, this kind of
|  "optimization" is NOT RECOMMENDED, and new implementations MUST
|  NOT do that optimization.
|  
|  
|  So, this is not reccomended i.e. if you do that and something breaks,
|  then it is your problem.
|  
|  So the question is whether we want to account for these type of hosts or
|  not.
|  
|  As i mentioned earlier, i don't have a problem with doing that. I would
|  be interested in hearing what other people have to say about this.
|  
|  
|  Regards, marcelo
|  
|  
|  > Best regards,
|  >
|  > Robin
|  >
|  > ----- 原邮件 -----
|  > 发件人: marcelo bagnulo braun <[email-masked]>
|  > 日期: 星期二, 十二月 1日, 2009 下午7:07
|  > 主题: Re: [savi] about draft-ietf-savi-fcfs-02
|  > 收件人: zhengruobin 35664 <[email-masked]>
|  > 抄送: [email-masked]
|  >
|  >
|  >> zhengruobin 35664 escribió:
|  >>
|  >>> Hi Marcelo,
|  >>>
|  >>>  In the draft-ietf-savi-fcfs-01, it proposes " if the address
|  >>>
|  >> contained in the newly created entry is a link
|  >>
|  >>> local address, FCFS SAVI MAY as well create entries for the
|  >>>
|  >> global addresses resulting from concatenating the
|  >>
|  >>> Interface Identifier of the link local address and the global
|  >>>
|  >> prefixes contained in the Prefix List for the Interface through
|  >>
|  >>> which the NSOL message was received." However, this is missing
|  >>>
|  >> in draft-ietf-savi-fcfs-02.
|  >>
|  >>> I don't know what was the original purpose of this optimization
|  >>>
|  >> for addressing. But it seems to me that it may be used to discover
|  >> the user's global address by SAVI device in case of SLAAC.
|  >>
|  >>>
|  >>>
|  >> But the node will do a DAD for the gloabl address as well, right?
|  >> so the
|  >> savi device will learn it when that happens, right?
|  >>
|  >> That is why i said it is an optimization.
|  >> What am i missing?
|  >>
|  >> regards, marcelo
|  >>
|  >>
|  >>
|  >>> Best regards,
|  >>>
|  >>> Robin
|  >>>
|  >>>
|  >>> ----- 原邮件 -----
|  >>> 发件人: marcelo bagnulo braun <[email-masked]>
|  >>> 日期: 星期二, 十二月 1日, 2009 下午6:29
|  >>> 主题: Re: [savi] about draft-ietf-savi-fcfs-02
|  >>> 收件人: zhengruobin 35664 <[email-masked]>
|  >>> 抄送: [email-masked]
|  >>>
|  >>>
|  >>>
|  >>>> zhengruobin 35664 escribió:
|  >>>>
|  >>>>
|  >>>>> Hi marcelo,
|  >>>>>
|  >>>>> BRAS is the abbreviation of Broadband Remote Access Server,
|  >>>>>
|  >>>>>
|  >>>> which is defined by DSL Forum in TR101.
|  >>>>
|  >>>>
|  >>>>> In the IPv4 access network, the bindings of IPv6 address and a
|  >>>>>
|  >>>>>
|  >>>> port are done by DHCPv4 snooping. But in the IPv6 access
|  >>>>
|  >> network,
|  >>
|  >>>> the SLAAC may be used insteads of DHCPv6 for IPv6 address
|  >>>> assignment. Thus, in case of SLAAC, a mechanism to discover the
|  >>>> bindings of IPv6 address and a port is needed.
|  >>>>
|  >>>>
|  >>>>>
|  >>>>>
|  >>>>>
|  >>>> make sense
|  >>>> AFIAU, this is covered int he new version of the draft... what
|  >>>>
|  >> do you
|  >>
|  >>>> think it is missing?
|  >>>>
|  >>>> I mean, the particular text you are pointing out was an
|  >>>> optimization for
|  >>>> the in order to automatically create the binding for the gloabl
|  >>>> addresses once the binding for the local address has been
|  >>>>
|  >> created. I
|  >>
|  >>>> don't have any problem with that optimization, but i think it
|  >>>>
|  >> changes>> much the resulting baheviour.
|  >>
|  >>>> So, i am not sure what do you think it is missing in order to
|  >>>>
|  >> support>> the case you describe.
|  >>
|  >>>> Regards, marcelo
|  >>>>
|  >>>>
|  >>>>
|  >>>>> Robin
|  >>>>>
|  >>>>> ----- 原邮件 -----
|  >>>>> 发件人: marcelo bagnulo braun <[email-masked]>
|  >>>>> 日期: 星期六, 十一月 28日, 2009 下午4:27
|  >>>>> 主题: Re: [savi] about draft-ietf-savi-fcfs-02
|  >>>>> 收件人: robin <[email-masked]>
|  >>>>> 抄送: [email-masked]
|  >>>>>
|  >>>>>
|  >>>>>
|  >>>>>
|  >>>>>> robin escribió:
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> Hi marcelo,
|  >>>>>>> In IPv4 world, there is a binding of IPv4 address and port
|  >>>>>>>
|  >> in
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> BRAS
|  >>>>>>
|  >>>>>> what is bras?
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> for the
|  >>>>>>> sake of security. When migration to IPv6, we do need a
|  >>>>>>>
|  >> method
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>> to
|  >>>>
|  >>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> bind the
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> IPv6 address and its corresponding port.
|  >>>>>>> The optimization defined by the MAY in draft-ietf-savi-fcfs-
|  >>>>>>>
|  >> 01
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> provided a
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> practical solution for this.
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> i am not sure i follow (fwiwi i am not oposing to this, i
|  >>>>>>
|  >>>>>>
|  >>>> simply
|  >>>>
|  >>>>
|  >>>>>> fail to
|  >>>>>> understnad what you are saying)
|  >>>>>> even without this optimization, we can create a binding for
|  >>>>>>
|  >> any
|  >>
|  >>>>>> IPv6
|  >>>>>> address and a port, so i am not sure i understnad what is
|  >>>>>>
|  >> your
|  >>
|  >>>>>>
|  >>>>>>
|  >>>> point.>>
|  >>>>
|  >>>>
|  >>>>>> The only potential issue that i understnad this optimization
|  >>>>>>
|  >> is
|  >>
|  >>>>>> addressing, is the case of legacy implementations, that
|  >>>>>>
|  >> follow
|  >>
|  >>>>>> 2462
|  >>>>>> instead of 4862 that may not do the DAD for the global
|  >>>>>>
|  >> address
|  >>
|  >>>>>>
|  >>>>>>
|  >>>> if
|  >>>>
|  >>>>
|  >>>>>> they
|  >>>>>> have done so for the corresponding link local.
|  >>>>>>
|  >>>>>> Regards, marcelo
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> Best Regards,
|  >>>>>>>
|  >>>>>>> Robin
|  >>>>>>>
|  >>>>>>> -----Original Message-----
|  >>>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
|  >>>>>>> Sent: Friday, November 27, 2009 3:26 PM
|  >>>>>>> To: zhengruobin 35664
|  >>>>>>> Cc: [email-masked]
|  >>>>>>> Subject: Re: [savi] about draft-ietf-savi-fcfs-02
|  >>>>>>>
|  >>>>>>> zhengruobin 35664 escribió:
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>> Hi There,
|  >>>>>>>>
|  >>>>>>>> In the draft-ietf-savi-fcfs-01, there is a description as
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> follows in
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>> 3.2.2.  Processing of control packets of draft-ietf-savi-
|  >>>>>>>
|  >> fcfs-01:
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>> "If no NADV message for that Target Address is received in
|  >>>>>>>>          DADTimeout, then the status of the entry is change
|  >>>>>>>>
|  >>>>>>>>
|  >>>> to
|  >>>>
|  >>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> valid and
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>>          the lifetime of the entry is set to LIFETIME.  In
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> addition, if
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>>          the address contained in the newly created entry
|  >>>>>>>>
|  >> is
|  >>
|  >>>>>>>>
|  >>>>>>>>
|  >>>> a link
|  >>>>
|  >>>>
|  >>>>>>>>          local address, FCFS SAVI MAY as well create
|  >>>>>>>>
|  >> entries
|  >>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> for the
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>>          global addresses resulting from concatenating the
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> Interface>>          Identifier of the link local address and
|  >>>>>>
|  >>>>>>
|  >>>> the
|  >>>>
|  >>>>
|  >>>>>> global prefixes
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>>          contained in the Prefix List for the Interface
|  >>>>>>>>
|  >>>>>>>>
|  >>>> through
|  >>>>
|  >>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> which>>          the NSOL message was received."
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>> But the above is not covered in the draft-ietf-savi-fcfs-
|  >>>>>>>>
|  >> 02.
|  >>
|  >>>>>>>>
|  >>>>>>>>
|  >>>> I
|  >>>>
|  >>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>> wonder what
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>> happened to this.
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>> i understand you are talking about the optimization defined
|  >>>>>>>
|  >> by
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> the MAY,
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> right?
|  >>>>>>> since the version 01 has been through a major rewriting,
|  >>>>>>>
|  >> this
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> was
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> dropped unitentionally.
|  >>>>>>>
|  >>>>>>> I will include it in the next version if people still think
|  >>>>>>>
|  >> it
|  >>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>> is a good
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>> idea
|  >>>>>>>
|  >>>>>>> regards, marcelo
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>> Best regards,
|  >>>>>>>>
|  >>>>>>>> Robin
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>> _______________________________________________
|  >>>>>>>> savi mailing list
|  >>>>>>>> [email-masked]
|  >>>>>>>> https://www.ietf.org/mailman/listinfo/savi
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>>
|  >>>>>
|  >>>>>
|  >>>>>
|  >>>>
|  >>>>
|  >>>
|  >>>
|  >>
|  >
|  >
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: zhengruobin 35664 <[email-masked]>
Date: Wed, 02 Dec 2009 01:22:35 +0800

Hi Alberto,

As far as a wireless interface between the SAVI device and mobile user is concerned, the DAD for all the global addresses seems making no sense. Can you imagine how much bandwidth in the wireless interface consumes by the DAD procedure for all the global addresses.

In order to prevent that, usually the router will allocate different prefix to different mobile user or access loop such that the global address of different user will not be duplicated. So I don't see the necessarity to do the DAD for global addresses in all cases.

Best regards,

Robin

----- 原邮件 -----
发件人: Alberto García <[email-masked]>
日期: 星期二, 十二月 1日, 2009 下午10:52
主题: RE: [savi] about draft-ietf-savi-fcfs-02
收件人: 'marcelo bagnulo braun' <[email-masked]>, 'zhengruobin 35664' <[email-masked]>, 'SAVI Mailing List' <[email-masked]>

> Even if hosts don't do DAD for global addresses and SAVI does not 
> create a binding for the global address 'resulting' from the LLA 
> when the LLA address does DAD, I don't see much problem.
> (fcfs-v02): the reception of a data packet with the global address 
> as source address when the SAVI device is in NO_BIND state 
> triggers a 2xDAD_NSOL that is sent through the Trusted ports and 
> moves to TENTATIVE. Unless there is a binding in other SAVI device 
> and a host has the address configured, the timer expires and state 
> moves to VALID. 
>

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 2 Dec 2009 11:47:36 +0800

Hi Robin,

This is a situation. If the router knows different users will use different
addresses, surely there is no need to depend on DAD snooping. Actually, it
can perform prefix level filtering instead, with the same performance as
address level filtering in this case.

But I have some questions,
1. In the position of host, does it knows it has a unique prefix and there
is no need to perform DAD? I mean, will the DAD procedure be left out in
reality?
2. I can't imagine how much bandwidth will be consumed by DAD procedure.
Isn't only one packet for each address in total?

Best Regards,
Guang

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> zhengruobin 35664
> Sent: Wednesday, December 02, 2009 1:23 AM
> To: Alberto Garc í a
> Cc: 'SAVI Mailing List'
> As far as a wireless interface between the SAVI device and mobile user is
> concerned, the DAD for all the global addresses seems making no sense. Can
> you imagine how much bandwidth in the wireless interface consumes by the
> DAD procedure for all the global addresses.
> 
> In order to prevent that, usually the router will allocate different
prefix to
> different mobile user or access loop such that the global address of
different
> user will not be duplicated. So I don't see the necessarity to do the DAD
for
> global addresses in all cases.
> 
> Best regards,
> 
> Robin
> 
> ----- 原邮件 -----
> 收件人: 'marcelo bagnulo braun' <[email-masked]>, 'zhengruobin 35664'
> <[email-masked]>, 'SAVI Mailing List' <[email-masked]>
> 
> > Hi
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 02 Dec 2009 09:36:59 +0100

> In order to prevent that, usually the router will allocate different prefix to different mobile user or access loop such that the global address of different user will not be duplicated. So I don't…
but the same argument would apply to the link local address, right?

Regards, marcelo

---

From: zhengruobin 35664 <[email-masked]>
Date: Wed, 02 Dec 2009 22:08:25 +0800

Yes. I think the working group should do something to migrate the side effect of DAD. What do you guys think?

Best regards,

Robin

----- 原邮件 -----
发件人: marcelo bagnulo braun <[email-masked]>
日期: 星期三, 十二月 2日, 2009 下午4:37
主题: Re: [savi] about draft-ietf-savi-fcfs-02
收件人: zhengruobin 35664 <[email-masked]>
抄送: Alberto García <[email-masked]>, 'SAVI Mailing List' <[email-masked]>

> > As far as a wireless interface between the SAVI device and 
> mobile user is concerned, the DAD for all the global addresses 
> seems making no sense. Can you imagine how much bandwidth in the 
> wireless interface consumes by the DAD procedure for all the 
> global addresses.
> >
> > In order to prevent that, usually the router will allocate 
> different prefix to different mobile user or access loop such that 
> the global address of different user will not be duplicated. So I 
> don't see the necessarity to do the DAD for global addresses in 
> all cases.
> >
> >   
> > 收件人: 'marcelo bagnulo braun' <[email-masked]>, 'zhengruobin 
> 35664' <[email-masked]>, 'SAVI Mailing List' <[email-masked]>
> >
> >   
> >> Hi
> >>
> >> |  > A DAD for a LLA is mandatory. But a DAD for a global 
> address 
> >> is not
> >> |  mandatory.
> >> Any problem with this behavior? (apart from loosing - buffering 
> - 
> >> some data packets)
> >>
> >> Regards,
> >> Alberto
> >>
> >>     
> >
> >
> >   
> 
>

---

From: Hongyu Li <[email-masked]>
Date: Wed, 02 Dec 2009 23:21:05 +0800

DAD for LLA is definitely useful in certain cases. Pls refer to the  
slides from Dave Allen, the BBF A&T co-chair, which were presented in  
SAVI in 76th meeting.

cheers,
Hongyu

在 2009-12-2，下午4:36， marcelo bagnulo braun 写道：

>> As far as a wireless interface between the SAVI device and mobile  
>> user is concerned, the DAD for all the global addresses seems  
>> making no sense. Can you imagine how much bandwidth in the wireless  
>> interface consumes by the DAD procedure for all the global addresses.
>>
>> don't see the necessarity to do the DAD for global addresses in all  
>> cases.
>>
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 02 Dec 2009 17:55:13 +0100

zhengruobin 35664 escribió:
> Yes. 

by yes, you mean that the same problem occurs with link locals, right?

If so, this is just one more case where the DAD packet is not present
for an address. This can be handled by triggering the proxy DAD upon the
reception of data apcket,s which is already in the current version of
the draft.

Regards, marcelo

> I think the working group should do something to migrate the side effect of DAD. What do you guys think?
>
> Best regards,
>
> Robin
>
> ----- 原邮件 -----
>>>> Even if hosts don't do DAD for global addresses and SAVI does 
>>>>         
>> not 
>>     
>>>> create a binding for the global address 'resulting' from the 
>>>>         
>> LLA 
>>     
>>>> (fcfs-v02): the reception of a data packet with the global 
>>>>         
>> address 
>>     
>>>> triggers a 2xDAD_NSOL that is sent through the Trusted ports 
>>>>         
>> and 
>>     
>>>> moves to TENTATIVE. Unless there is a binding in other SAVI 
>>>>         
>> device 
>>     
>>>> and a host has the address configured, the timer expires and 
>>>>         
>> state 
>>     
>>>> moves to VALID. 
>>>>