Subject: Re: [Softwires] routing loop issue//re: Please review 6rd

From: Xu Xiaohu <[email-masked]>
Date: Thu, 21 Jan 2010 15:42:11 +0800

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年1月19日 20:59
> 收件人: 'Rémi Després'
> 抄送: 'Mark Townsley'; [email-masked]'
> 主题: re: routing loop issue//re: [Softwires] Please review 6rd
> 
> 
> 
> > -----邮件原件-----
> > 发件人: Rémi Després [mailto:[email-masked]]
> > 发送时间: 2010年1月19日 19:06
> > 收件人: Xu Xiaohu
> > 抄送: 'Mark Townsley'; [email-masked]
> > 主题: Re: routing loop issue//re: [Softwires] Please review 6rd
> >
> >
> > Le 19 janv. 2010 à 11:01, Xu Xiaohu a écrit :
> >
> > >>>
> > >>> By the way, would it be better for preventing the routing loops if
there
> > >>> were some well-known bits in the 6rd prefix?
> > >>
> > >> This would IMHO add complexity, unnecessarily since routing loops
> > >> are avoided
> > >>  with the described ingoing and outgoing filters in the BRs.
> > >
> > > Sorry for late response. Will this approach of blindly filtering any
packet
> > > sourced from the BRs drop the normal tunneled packets mistakenly?
> >
> >
> > The draft says:
> >    To avoid forwarding loops via other internal relays, the BR should
> >    employ outgoing and incoming IPv4 packets filters, filtering out all
> >    known relay addresses for internal 6rd BRs, ISATAP routers or 6to4
> >    relays, including the well known anycast address space for 6to4.
> >
> > In my understanding, this will not filter any packet that should be
forwarded.
> 
> If there is a softwire tunnel between two BRs, wouldn't the packet
tunneled
> in the softwire be filtered blindly?

    +------------------------+
    |                        |
    |                        |
    |     IPv6 Internet      |
    |                        |
    +------+----------+------+
           |          |
           |          |
        +--+--+     +--+--+
    +---+6rd-A+-----+6rd-B+--+
    |   +-----+     +-----+  |
    |                        |
    |        IPv4 ISP        |
    |       +-------+        |
    +-------+ CPE-1 +--------+
            +---+---+
                |
          +-----+-----+
          |           |
          | IPv6 Site |
          +-----------+

In the above scenario, two 6rd BRs are configured with the same address for
anycast service. Assuming the nearest 6rd BR for the CPE is 6rd-A, all IPv6
packets from the IPv6 site and destined to the IPv6 internet will be
tunneled towards 6rd-A by the CPE. Once 6rd-A lost connections to the IPv6
Internet, some failover mechanism should be used to direct these packets
towards 6rd-B. One possible solution is: 6rd-A withdraws the route to the
IPv6 Internet, which was advertised in IPv4 ISP network previously, as soon
as its connection to the IPv6 Internet is lost. Another solution is:
establish a softwire tunnel between the two 6rd BRs for failover route. With
the latter solution, some normal packets tunneled in the softwire during
failover will be filtered mistakenly.

Xiaohu

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Jan 2010 09:03:47 +0100

Le 21 janv. 2010 à 08:42, Xu Xiaohu a écrit :

> towards 6rd-B.

> One possible solution is: 6rd-A withdraws the route to the
> as its connection to the IPv6 Internet is lost.

This is in my understanding the right solution, precisely because protection against routing loops can be achieved by preventing tunnels between BRs.

> Another solution is:

That's why the other solution should be preferred.

RD

---

From: WashamFan <[email-masked]>
Date: Thu, 21 Jan 2010 17:31:29 +0800

Hi,

If 6rd-A and 6rd-B belong to the same 6rd domain, I don't see the routing loops.

washam

----- Original Message -----
From: Rémi Després <[email-masked]>
Date: Thursday, January 21, 2010 4:04 pm
Subject: Re: [Softwires] routing loop issue//re:  Please review 6rd
To: Xu Xiaohu <[email-masked]>
Cc: [email-masked]

>  This is in my understanding the right solution, precisely because 
> protection against routing loops can be achieved by preventing tunnels 
> between BRs.
>  
>  
>  > Another solution is:
>  _______________________________________________
>  Softwires mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Jan 2010 10:51:23 +0100

> If 6rd-A and 6rd-B belong to the same 6rd domain, I don't see the routing loops.

This a limit case, but if a BR accepts tunnels toward other BRs of the same domain, an IPv6 Internet host with a spoofed source address can initiate a loop:

    v6dst = v6src = PA.Aa 

   +------------------------+
   |          ====>         |
   |                        |
   |     IPv6 Internet      |
   |                        |
   +------+-----------+-----+
          |           |
          |prefix PA  |prefix PA
       +--+--+     +--+--+
   +---+6rd-A+-----+6rd-B+--+
   |   +-----+     +-----+  |
   | address Aa  address Aa |
   |          <====         |
   |                        |
   |        IPv4 ISP        |
   +------------------------+

Regards,
RD

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 21 Jan 2010 18:00:54 +0800

> -----邮件原件-----
> 发件人: WashamFan [mailto:[email-masked]]
> 发送时间: 2010年1月21日 17:31
> 收件人: Rémi Després
> 抄送: Xu Xiaohu; [email-masked]
> 主题: Re: [Softwires] routing loop issue//re: Please review 6rd
> 
> Hi,
> 

Yes, in case that the two 6rd BR use the same 6rd prefix which is almost
Provider-Independent IPv6 address.

However, if the two BRs use different 6rd prefixes, that is to say, each BR
was allocated a PA address for 6rd prefix from its own upstream IPv6 ISP,
there is a possibility of routing loop.

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 22 Jan 2010 09:39:59 +0800

> 发送时间: 2010年1月21日 17:51
> 收件人: WashamFan
> > If 6rd-A and 6rd-B belong to the same 6rd domain, I don't see the
routing
> loops.
> 
> This a limit case, but if a BR accepts tunnels toward other BRs of the
same
> domain, an IPv6 Internet host with a spoofed source address can initiate a
>     v6dst = v6src = PA.Aa

Assuming 6rd-A receives a packet with v6dst = v6src = PA.Aa.x from the IPv6
Internet, will it forward a tunneled packet (after 6rd encapsulation) whose
IPv4 destination address is itself (i.e., the anycase address Aa)? By the
way, if the strict uRPF is enabled on 6rd-A, the above IPv6 packet should be
dropped before performing 6rd encapsulation. Correct?

Xiaohu

---

From: WashamFan <[email-masked]>
Date: Fri, 22 Jan 2010 10:04:17 +0800

Hi,

>  dropped before performing 6rd encapsulation. Correct?

That is exactly the reason why I said no routing loop between BRs in the
same 6rd domain. Note that even the attacker use the unicast address instead
of  the anycast address, it does not work either.

washam

---

From: Rémi Després <[email-masked]>
Date: Fri, 22 Jan 2010 09:42:29 +0100

Le 22 janv. 2010 à 02:39, Xu Xiaohu a écrit :

> IPv4 destination address is itself (i.e., the anycase address Aa)?

In the absence of security check, yes it would forward it.
(This is precisely the reason for having, for security, outgoing filters that eliminate all IPv4 destinations that are BR IPv4 addresses).

> By the

If IPv6 packets entering a 6rd BR traverses an IPv6 routing function before entering the 6rd function, and if this function has the strict RPF activated, yes you are right: the IPv4 outgoing filter may not include the BR IPv4 address of the BR itself.
IMHO, however, including it always may not be, even in this particular configuration, a significant waste.
In any case, this remains an implementation choice. 

RD