Subject: [savi] Fw: savi-dhcp-03 comments

From: "Bi Jun" <[email-masked]>
Date: Sat, 12 Jun 2010 12:52:07 +0800

Hi Christian,

Thank you for your explanation, please see my reply below.

--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Friday, June 11, 2010 5:59 AM
To: "Jun Bi" <[email-masked]>
Cc: "Lin Tao" <[email-masked]>; "SAVI Mailing List" <[email-masked]>; 
"Jean-Michel Combes" <[email-masked]>
Subject: Re: [savi] savi-dhcp-03 comments

> Jun,
>
> continuing on a few points in our discussion:
>
>>>> 2. We think the detection state is necessary because the dhcp address
>>>> assignment needs this step to finish configuration of a DHCP address. 
>>>> This
>>>> state machine in the savi-dhcp draft had been proposed more than 1 
>>>> year, and
>>>> we didn't see anybody in the WG were not comfortable with it.
>>>
>>> I am sure the state machine works fine as currently specified.  But I 
>>> believe it can be simplified.
>>
>> I guess you meant to delete the "detection" state in your last email. If 
>> you are OK with it, then that's good.
>
> Hmm, I am not sure if we are on the same page.  So let me follow up a bit: 
> The current state machine captures every phase of DHCP-based address 
> configuration, from the transmission of a host's DHCP Discovery message, 
> to the final double-check DAD procedure.  My view is that such detail is 
> not necessary for the purpose of SAVI.  We would achieve nearly the same 
> if SAVI devices created bindings simply based on a DHCP Acknowledgment 
> message -- without tracking any other message.  The benefits of tracking 
> other messages are, in my opinion, very small and do not justify the extra 
> overhead.
>

The savi-dhcp is a solution used for the dhcp address assignment 
environment.
Then we should strictly follow the requirement of dhcp assignment rfc.
Please note that, the binding setup procedure is only for the dhcp address, 
not for slaac address.
If there are more than one dhcp server, or there are manual configuration 
co-existence, then the detection phase is very useful.

>>>> 3. Agree not to be stated in this document, but as I said during my
>>>> savi-dhcp ppt presentation in the Hiroshima WG meeting, we suggest this 
>>>> to
>>>> be mentioned in framework document. In current savi solution(especially
>>>> slaac), addresses with bogus prefixes will also be bound and allowed. 
>>>> This
>>>> limitation should be specified.
>>>
>>> Right.  But the SAVI approach towards the validation of prefixes is not 
>>> to use enforcement in SAVI devices, but rather to rely upon:
>>>
>>> - Trust in DHCP servers, and
>>>
>>> - Ingress filtering in the first-hop router.
>>
>> I really think the prefix configuration by RA snooping, DHCP-PD protocol, 
>> or manual configuration at savi-switch will be better.
>>
>> It's not good to rely on ingress filtering, when savi is enabled, it's 
>> not sure ingress filtering is 100% enforced.
>
> You are, of course, welcome to this opinion, but the working group 
> decided, very early in the process, that SAVI would complement ingress 
> filtering and not replace it.  The current SAVI solution for DHCP does 
> replace ingress filtering, and hence goes against this previous decision. 
> Furthermore, the replacement of ingress filtering comes at a 
> non-negligible cost in terms of extra implementation complexity and/or 
> extra configuration overhead.
>
> Let's therefore take out the ingress filtering alternative from the SAVI 
> solution for DHCP.  Vendors may implement it, but it should be part of the 
> standard.
>

I know the SAVI doesn't want to replace ingress filtering.
But the purpose of prefix configuration function was not considered to 
replace ingress filtering.

Firs first reason is that: SAVI is a way to anti-spoofing at local link 
level.
Then if the destination address of packet is inside local link, then the 
ingress filtering at a router will not drop this kind of packet, but the 
prefix configuration function at savi switch will drop the packet.

Second, it's a multi-fence way to make the network more secure and early 
dropping of packets will save the bandwidth in the local link.

For the implementation complexity, it's very simple and implementable, 
compared with the data-trigger function.

thanks,
Jun Bi

> - Christian
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Jun 2010 11:47:16 -0700

Jun, 

I understand your view better now, but I still don't agree that SAVI
devices should learn, and enforce, address prefixes explicitly,
especially not in the case of SAVI for DHCP.  The conceptual model of
SAVI for DHCP is that DHCP servers have address authority, and that SAVI
devices enforce the addresses assigned by DHCP servers.  Since DHCP
servers assign full addresses, including prefixes, I don't see a reason
to check address prefixes explicitly.  In fact, an explicit check would
even open a new, difficult-to-answer question:  What would happen if the
prefix in a DHCP-assigned address does not match the prefix that the
SAVI device had learned?

- Christian

On Jun 11, 2010, Bi Jun wrote:

>> solution for DHCP.  Vendors may implement it, but it should be part of 
>> the standard.
>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 22 Jun 2010 10:23:05 +0800

Hi Christian,

Thank for the comments.

I think the network admin may have the choices: either to trust the dhcp 
server,
or dynamically (by DHCP-PD snooping or RA snooping) or statically configure 
the savi switch.

Again, as I stated during my PPT and email, this is common for both dhcp and 
slaac cases, then it can be contributed to the framework document.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Tuesday, June 22, 2010 2:47 AM
To: "Bi Jun" <[email-masked]>
Cc: "Lin Tao" <[email-masked]>; "SAVI Mailing List" <[email-masked]>; 
"Jean-Michel Combes" <[email-masked]>
Subject: Re: [savi] savi-dhcp-03 comments

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 22 Jun 2010 12:27:03 +0800

Christian:

I think for slaac address, the necessity of prefix check is explicit. Or
else, a node can use the address out of the link to perform a typical
Man-in-the-middle attack against other nodes on link. All the attacker must
do is performing a DAD or even nothing if data trigger is allow. I think
this leak will make SAVI look stupid.

For DHCP, I agree it is proper to choose to trust DHCP server. However,
bogus DHCP servers are everywhere. Users not familiar with network may start
the DHCP server process on their computers totally unconsciously. Unless
SAVI is fully deployed, just binding anchor based check cannot prevent bogus
DHCP server effectively. Generally, a host will get assigned a non-routable
address from the bogus DHCP servers and broken from network. Filtering the
DHCP reply with prefix not in the allowed scope will be really useful.
On the other hand, SAVI will be easily bypassed if the attacker attached to
SAVI switch can manipulate a bogus DHCP server. This will be a serious leak.

Best regards,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Vogt
> To: Bi Jun
> Cc: Lin Tao; SAVI Mailing List; Jean-Michel Combes

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Jun 2010 00:58:03 -0400

My understanding is that SAVI was supposed to be kept simple, and focus 
on a specific problem.

With DHCP, the problem of false servers is a distinct problem, and 
addressed by port configurations and related mechanisms.  SAVI should 
not be trying to second-guess DHCP.
To put it another way, if SAVI starts second-guessing DHCP, the network 
admin will get inexplicable calls about failures to communicate.

With regard to SLAAC, one can make an argument that a misbehaving host 
could choose to use a false prefix.   SAVI's job, as currently defined, 
is to make sure that the admin knows who did so, and that no-one else is 
using the same 128 bit address.
Note that there are two po0ssible failures that could lead to this in 
the SLAAC case.
It could be a seriously misbehaving host.  We would like to stop that 
(in the abstract).  But it could also be a router emit improper RAs. 
And if so, again, if SAVI blocks the packets we will get inexplicable 
failures of communication.

On top of that, requiring that SAVI devices be configured with the 
proper prefix means that a LOT more configuration has to take place, 
with a concomitant potential for a lot more misconfiguration.

Yours,
Joel

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 22 Jun 2010 08:28:03 +0200

afaict, SAVI is supposed to complement ingress filtering.
So, if we have ingress filtering, we essentially have a mean to validate 
if the prefix comes from the right part of the topology.
SAVI complements it by ginve the finer granularty at the host level.

How ingress filtering is configured would be out of the scope for savi imho.

makes sense?

Regards, marcelo

El 22/06/10 6:58, Joel M. Halpern escribió:
> My understanding is that SAVI was supposed to be kept simple, and 
> focus on a specific problem.
>
> To put it another way, if SAVI starts second-guessing DHCP, the 
> network admin will get inexplicable calls about failures to communicate.
>
> could choose to use a false prefix.   SAVI's job, as currently 
> defined, is to make sure that the admin knows who did so, and that 
> no-one else is using the same 128 bit address.

---

From: "Bi Jun" <[email-masked]>
Date: Tue, 22 Jun 2010 14:33:42 +0800

1 I don't think it will replace ingress filtering, as I stated in the email 
replied to Christian.
2 I think if the network admin can have the choice to configure or not 
configure will be better, so it can be an option.
3 Having such a mechanism is easy and low cost to be implemented. It doesn't 
make the savi solution more complicated. The mechanism that really make savi 
solution not easy to be implemented is the data-triggered binding.

thanks,
Jun Bi

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Tuesday, June 22, 2010 2:28 PM
To: <[email-masked]>
Subject: Re: [savi] savi-dhcp-03 comments

>> addressed by port configurations and related mechanisms.  SAVI should not 
>> be trying to second-guess DHCP.
>> Note that there are two po0ssible failures that could lead to this in the 
>> SLAAC case.
>> It could be a seriously misbehaving host.  We would like to stop that (in 
>> the abstract).  But it could also be a router emit improper RAs. And if 
>> so, again, if SAVI blocks the packets we will get inexplicable failures 
>> of communication.
>>
>> On top of that, requiring that SAVI devices be configured with the proper 
>> prefix means that a LOT more configuration has to take place, with a 
>> concomitant potential for a lot more misconfiguration.
>>
>> Yours,
>> Joel
>>
>> Guang Yao wrote:
>>> Christian:
>>>

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 22 Jun 2010 14:59:37 +0800

If choosing not to trust RA because routers may emit improper RA, why not
choosing not to trust DHCP reply because DHCP server may reply improperly,
based on the same logic?

I don't think administrator can always get known who is spoofing from the
binding record. There is no unlimited binding entry resource. Garbage
collection mechanism will remove expired binding entry. And why cannot SAVI
device filter obviously spoofed address?

Best regards,
Guang

Joel
> M. Halpern
> Sent: Tuesday, June 22, 2010 12:58 PM
> To: Guang Yao
> Cc: 'Lin Tao'; 'SAVI Mailing List'; 'Christian Vogt'; 'Jean-Michel Combes'

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 22 Jun 2010 15:04:10 +0800

I agree. Spoofing packet targeting at host on the same link will never be
filtered by ingress filtering.

Best regards,
Guang

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bi
> Jun
> Sent: Tuesday, June 22, 2010 2:34 PM
> To: marcelo bagnulo braun; [email-masked]
the
> >> It could be a seriously misbehaving host.  We would like to stop that
(in
> >> On top of that, requiring that SAVI devices be configured with the
proper
> >>> On the other hand, SAVI will be easily bypassed if the attacker
attached

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 22 Jun 2010 09:28:39 +0200

> filtered by ingress filtering.
ah! I see what you mean now.
Yes,i agree, this won't be protected by ingress filtering.

It would be possible for the SAVI device to learn the prefix from the 
RAdv, as long it verifies that the RAdv comes from a trusted port.

Regards, marcelo

>> 1 I don't think it will replace ingress filtering, as I stated in the
>>      
> email
>    
>> replied to Christian.
>> 3 Having such a mechanism is easy and low cost to be implemented. It
>>      
> doesn't
>    
>> make the savi solution more complicated. The mechanism that really make
>>      
> savi
>    
>> From: "marcelo bagnulo braun"<[email-masked]>
>> To:<[email-masked]>
>> not
>>>> is to make sure that the admin knows who did so, and that no-one else
>>>>          
> is
>    
>>>>> I think for slaac address, the necessity of prefix check is explicit.
>>>>>            
> Or
>    
>>>>> do is performing a DAD or even nothing if data trigger is allow. I
>>>>>            
> think
>    
>>>>> For DHCP, I agree it is proper to choose to trust DHCP server.
>>>>>            
> However,
>    
>>>>> the DHCP server process on their computers totally unconsciously.
>>>>>            
> Unless
>    
>>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>>              
> Of
>    
>>>>>> Christian Vogt
>>>>>> servers assign full addresses, including prefixes, I don't see a
>>>>>>              
> reason
>    
>>>>>> to check address prefixes explicitly.  In fact, an explicit check
>>>>>>              
> would
>    
>>>>>>>> Let's therefore take out the ingress filtering alternative from the
>>>>>>>>                  
>>>>> SAVI
>>>>>            
>>>>>>> But the purpose of prefix configuration function was not considered
>>>>>>>                
> to
>    
>>>>>>> For the implementation complexity, it's very simple and
>>>>>>>                
> implementable,
>

---

From: Christian Vogt <[email-masked]>
Date: Thu, 24 Jun 2010 14:18:53 -0700

Guang and all:

I understand Guang's comparison between the authority of DHCP servers
versus first-hop routers.  But the benefit-cost tradeoff is different
in the two cases, and so I think we should consider them separately:

The model of SAVI for DHCP is inherently based on the authoritativeness
of DHCP servers over full addresses.  And I don't see extra benefit in
giving SAVI devices an authority as well.  While it is true that
misbehavior of a DHCP server could lead to disruption, extra
configuration of SAVI devices to penalize such misbehavior wouldn't
mitigate the problem.  Given that such extra configuration would also go
against the working group objective of keeping its standards simple, I
advise against the extra configuration in the case of SAVI for DHCP.

The model of SAVI for SLAAC is based on the authoritativeness of
first-hop routers over address prefixes.  And an argument could be made
to have SAVI devices learn address prefixes from first-hop routers, just
as they learn full addresses from DHCP servers in the case of SAVI for
DHCP.  But in that case, the learning should happen automatically in my
opinion, i.e., without extra configuration of SAVI devices.

- Christian

On Jun 21, 2010, Guang Yao wrote:

> If choosing not to trust RA because routers may emit improper RA, why
> not choosing not to trust DHCP reply because DHCP server may reply
> improperly, based on the same logic?
> 
> I don't think administrator can always get known who is spoofing from
> the binding record. There is no unlimited binding entry resource.
> Garbage collection mechanism will remove expired binding entry. And why
> cannot SAVI device filter obviously spoofed address?
> 
> Best regards, Guang

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 25 Jun 2010 13:57:51 +0800

Christian:

Actually I agree with these views. It's better to leave the security problem
of DHCP to DHCP itself. Any improvement achieved through SAVI is costly.

For SLAAC, prefix validation is of obvious necessity. As no other protocols
are in charge of bogus prefix on local link, I suggest SAVI to take the
responsibility. Learning proper prefix from RA automatically is a practical
solution.

A MUST is proper for prefix validation in SLAAC. A MAY is proper in DHCP.

Best regards,
Guang

> Sent: Friday, June 25, 2010 5:19 AM
> To: Guang Yao
> Subject: [savi] SAVI device configuration with prefixes (Re: savi-dhcp-03
> comments)
> 
> Guang and all:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Jun 2010 10:48:24 -0400

Trying to perform prefix validation even for just SLAAC starts to get 
interesting with spanning tree changes or device reboots.

To give a simple example, we do not require that SAVI devices have 
non-volatile storage.  So, the network is working, and the non-adjacent 
savi device resets.
If it sees new data traffic, it should do data triggered operation.
Suppose it sees a new Neighbor solicitation?
The SAVI device has not seen an RA.  Is it supposed to block the NS, and 
  generate a response as if that address is already assigned?  Is it 
supposed to let the NS through, but block all the data traffic, even 
though the NS succeeded?  Is it supposed to generate an RS, and save 
enough state to be able to proceed when an RA is received?

Yes, I understand the attractiveness of putting in these kinds of features.
The most common downfall of any standard (IETF or otherwise) is feature 
creep, where extra "nice" features keep being added, such taht the 
standard becomes difficult to understand or implement correctly or 
interoperably.

Yours,
Joel

PS: I am still working on revising the threats document, but it 
distinctly looks like we do not agree on what the threats we want 
covered are.

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Jun 2010 09:02:59 -0700

Joel:

You are identifying an important problem.  Do you think it can be fixed
by having a SAVI device issue a Router Solicitation message after reset?

- Christian

On Jun 25, 2010, Joel M. Halpern wrote:

> savi device resets. If it sees new data traffic, it should do data
> triggered operation. Suppose it sees a new Neighbor solicitation? The
> SAVI device has not seen an RA.  Is it supposed to block the NS, and 
> Yes, I understand the attractiveness of putting in these kinds of
> features. The most common downfall of any standard (IETF or otherwise)
> is feature creep, where extra "nice" features keep being added, such
> taht the standard becomes difficult to understand or implement correctly
> or interoperably.
> 
> Yours, Joel
>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Jun 2010 09:28:14 -0700

Guang Yao wrote:

> A MUST is proper for prefix validation in SLAAC.

I personally tend to agree with this.

> A MAY is proper in DHCP.

I disagree; we should leave it out completely.  It would make the
standard more complex without adding a benefit.

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Jun 2010 12:55:17 -0400

My preference, personally, is not to try to solve every potential 
problem.  Rather, let us define a set of mechanisms and behaviors that 
can solve some clear and necessary issues.

If the working group insists on solving the problem of incorrect prefix 
usage in conjunction with SLAAC, then it seems likely that we will have 
to at least perform an RS.  It is not clear that is even sufficient. 
(There can be multiple routers.  They can have different prefixes they 
advertise.  All are legitimate.  We probably would need to do an RS 
under any spanning tree topology change, since there may have been 
information visible to the hosts that the SAVI device did not see.  I do 
not know if this is a comprehensive list of issues.)

Yours,
Joel

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 25 Jun 2010 19:08:07 +0200

Hi Guang,

2010/6/25 Guang Yao <[email-masked]>:
> responsibility.

This is already the case in FCFS proposal:

4.1.  FCFS SAVI Data structures

[snip]

   In addition to this, FCFS SAVI need to know what are the prefixes
   that are directly connected, so it maintains a data structure called
   the the FCFS SAVI prefix list, which contains:
   o  Prefix
   o  Interface where prefix is directly connected

[snip]

4.2.1.  Processing of transit traffic

[snip]

   o  If the data packet is received through a Validating port, then the
      SAVI function checks whether the received data packet is local
      traffic or transit traffic.  It does so by verifying if the source
      address of the packet belongs to one of the directly connected
      prefixes available in the receiving interface.  It does so by
      searching the FCFS SAVI Prefix List.
      *  If the IP source address does not belong to one of the local
         prefixes of the receiving interface, this means that the dat
         packet is transit traffic and the packet SHOULD be discarded.
         The FCFS SAVI function MAY send an ICMP Destination Unreachable
         Error back to the source address of the data packet.  (ICMPv6,
         code 5 (Source address failed ingress/egress policy) should be
         used).
      *  If the source address of the packet does belong to one of the
         prefixes available in the the receiving port, then the SAVI
         local traffic validation processes is executed as described
         below.

> Learning proper prefix from RA automatically is a practical
> solution.

Practical but, IMHO, it's dangerous: what does prevent a malicious
node to poison the Prefix Table?
You can use SEND to prevent such a case but that would require many
exchanges (i.e. cert check) and CPU consumption (i.e. signature
check).
You can also use RA-Guard which needs, IIRC, manual configuration and
so the SAVI device already knows the allowed prefixes.

BTW, if the SAVI device is a router, the SAVI device already knows the
allowed prefixes as they have been configured to be advertised.

Best regards.

JMC.

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Jun 2010 10:17:56 -0700

Joel M. Halpern wrote:

> [...] There can be multiple routers.  They can have different prefixes
> they advertise.  All are legitimate. [...]

I agree.  But it seems that a single Router Solicitation message, sent 
to the all-routers multicast address, would be enough, wouldn't it?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Jun 2010 10:43:42 -0700

Jean-Michel,

two comments:

- You are right that the SAVI For SLAAC document already includes the
  notion of a prefix table, but it currently does not tell how this
  table gets populated.  The assumption is manual configuration, of
  course.  But either this should be mentioned explicitly, or we
  should add a mechanism for automatic prefix table population based
  on Router Advertisement messages.  Of these two options, I am
  personally in favor of the latter, because it reduces configuration
  complexity and, hence, the risk for configuration errors.

- If the working group adopts automatic prefix table population based on
  Router Advertisement messages, then this mechanism would indeed have
  to be protected against spoofing.  One, in my opinion feasible, way
  to do this is by configuring SAVI devices with respect to which
  ports connect to first-hop routers.  This would be a mechanism
  analogous to the configuration of SAVI-For-DHCP devices with respect
  to which ports connect to DHCP servers.

Makes sense?

- Christian

On Jun 25, 2010, Jean-Michel Combes wrote:

> Hi Guang,
> 
>> Actually I agree with these views. It's better to leave the security
>> problem of DHCP to DHCP itself. Any improvement achieved through SAVI is
>> costly.
>> 
>> For SLAAC, prefix validation is of obvious necessity. As no other
>> protocols are in charge of bogus prefix on local link, I suggest SAVI to
>> take the responsibility.
> 
> In addition to this, FCFS SAVI need to know what are the prefixes that
> are directly connected, so it maintains a data structure called the the
> FCFS SAVI prefix list, which contains: o  Prefix o  Interface where
> prefix is directly connected
> 
> [snip]
> 
> SAVI function checks whether the received data packet is local traffic
> or transit traffic.  It does so by verifying if the source address of
> the packet belongs to one of the directly connected prefixes available
> in the receiving interface.  It does so by searching the FCFS SAVI
> Prefix List. *  If the IP source address does not belong to one of the
> local prefixes of the receiving interface, this means that the dat
> packet is transit traffic and the packet SHOULD be discarded. The FCFS
> SAVI function MAY send an ICMP Destination Unreachable Error back to the
> source address of the data packet.  (ICMPv6, code 5 (Source address
> failed ingress/egress policy) should be used). *  If the source address
> of the packet does belong to one of the prefixes available in the the
> receiving port, then the SAVI local traffic validation processes is
> executed as described below.
> 
>> Learning proper prefix from RA automatically is a practical solution.
> 
> Practical but, IMHO, it's dangerous: what does prevent a malicious node
> to poison the Prefix Table? You can use SEND to prevent such a case but
> that would require many exchanges (i.e. cert check) and CPU consumption
> (i.e. signature check). You can also use RA-Guard which needs, IIRC,
> manual configuration and so the SAVI device already knows the allowed
> prefixes.
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 25 Jun 2010 18:22:20 -0700

It is an important problem that we just went over when Joel brought it up a couple of months ago. Do we need to go over it again? In DHCP mode, this is why the switch generates a DHCP request (to snoop the response), and in SLAAC mode, why the switch generates a NS message to snoop the NA's.

>> distinctly looks like we do not agree on what the threats we want

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Fri, 25 Jun 2010 18:27:26 -0700

It was that context in which you asked me to write draft-baker-savi-one-implementation-approach-00.txt

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 26 Jun 2010 13:41:26 +0800

--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Saturday, June 26, 2010 1:43 AM
To: "Jean-Michel Combes" <[email-masked]>
Cc: "Lin Tao" <[email-masked]>; "Guang Yao" <[email-masked]>; "SAVI 
Mailing List" <[email-masked]>
Subject: Re: [savi] SAVI device configuration with prefixes

Hi Christian,

Please note that the port type "RA-Trust" was already proposed in 
draft-bi-savi-stateless-00/01. As I reported, this draft had been 
implemented by vendors joint CNGI-CERNET2 SAVI deployment project. So this 
"RA-Trust" port was ALREADY implemented by vendors and deployed in 
CNGI-CERNET2. Tsinghua University just did conformance testing for savi 
switches from 3Com, ZTE, Ruijie, and Digital China on this function in March 
and April.

Best Regards,
Jun Bi

10. Anchor Attributes

   This section specifies the anchor attributes involved in this
   mechanism.

   Anchor is defined in the [savi-framework]. Attribute of each anchor
   is configurable. In default, anchor has no attribute. An anchor MAY
   be configured to have one or more compatible attributes. However, an
   anchor MAY have no attribute.

   If an anchor has no attribute, in this solution, Router Advertisement
   message from this anchor MUST be dropped. However, other packets
   SHOULD NOT be dropped.

10.2. SAVI-RA-Trust Attribute

   If and only if an anchor is associated with a trustable router, it
   SHOULD be set to have this attribute.

   On a SAVI device enabled this solution, there may be no anchor with
   this attribute. This implies only link-local address is allowed, or
   prefix validation is not enabled, or only manually configured prefix
   is allowed. Router Advertisement message not coming from such anchors
   MUST be dropped.