Re: [v6ops] IPv6 link-local traffic questions

Toreless & Tony

I read through the draft for BIER over IPv6.

https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06

So since the BIER header bitmask that denotes the BFERs in the Domain to
replicate the multicast packets is encoded in the DestOp processed by the
BFER, the packets should not be forwarded past the BFER is my guess is with
ttl 255.  With IPv6 ND with ttl 255 example the packet can be forwarded
past the adjacent node but I have not seen that happen.  I believe Jen
Linkova on this thread has seen that. Since the BFER dest options has to
have the BIER bit mask encoding or the packet is dropped I believe is your
security protection from forwarding past the BIER with 255 ttl if you
decided to go that route.

Under BIERv6 packet processing should help if ttl 255 is used to prevent
forwarding outside of bier domain

A packet having a 'BIER Specific Handling' indication but not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3.2
<https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06#section-3.2>.

   A packet not having a 'BIER Specific Handling' indication but having
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

Under 5.3 security considerations should also help with ttl 255 and
forwarding outside of BIER domain

For a router incapable of BIERv6, such BIERv6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards

Gyan

On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Makes sense.
>
> Thanks
>
> Gyan
>
> On Sat, Mar 14, 2020 at 4:12 AM Karl Auer <kauer@biplane.com.au> wrote:
>
>> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
>> > I always wondered why RFC 4862 states that ND & RD packets have TTL
>> > 255.
>>
>> >From RFC4861:
>>
>>    "By setting the Hop Limit to 255, Neighbor Discovery
>>     is immune to off-link senders that accidentally or
>>     intentionally send ND messages.  In IPv4, off-link
>>     senders can send both ICMP Redirects and Router
>>     Advertisement messages."
>>
>> RFC4861 also requires RA and NA packets with any other TTL value to be
>> silently discarded by any receiving node.
>>
>> I can't find my original source, but my notes in a training course I
>> developed a while ago have this to say about why:
>>
>>    "Why does 255 mean “local source”? Because routers
>>     decrement the hop limit on packets passing through
>>     them, and discard packets where the hop count
>>     decrements to zero. It is impossible to decrement
>>     a one-byte counter to 255 without passing through
>>     zero, because 255 is the maximum value such a counter
>>     can have. So the value 255 means that the packet must
>>     have been generated on the local link."
>>
>> Probably would be better expressed as "must have originated on the
>> local link".
>>
>> Regards, K.
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Karl Auer (kauer@biplane.com.au)
>> http://www.biplane.com.au/kauer
>> http://twitter.com/kauer389
>>
>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com