Re: [v6ops] IPv6 link-local traffic questions

Yepp, that's personally I prefer on multicast TTL=1 (and also on ISIS &
e.g. on expired draft where we were carrying ISIS natively over IP). The
cost of a frame running away unintended multiple-hops in a control protocol
without a tunnel are simply NOT fun.  The cost of such a thing (and it
happened MORE than once) outweighs IMO the minor security advantage.

If you read v6 BIER drafts you should read
https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has been
published much, much earlier ...

--- tony

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

>
> 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
>
>
>
>