Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt

[Eric C Rosen <[e-mail]>]

Here are some comments and questions on draft-pfister-bier-over-ipv6.

Despite the title and abstract, the draft has nothing to do with the 
routing underlay.  It's about procedures for the BIER layer. Section 4 
is about BIER layer functions at the BFIR, and section 5 is about BIER 
layer functions at other BFRs.

The draft says in some places that BIER packets are "regular" IPv6 
packets, but it says in other places that they are not "regular" IPv6 
packets.  "Regular" is never defined, but it should be used consistently.

The term "BIER bits" occurs in contexts where it seems to mean "BIER 
BitString".  (The bits representing the SI are also "BIER bits", but 
don't seem to be included as "BIER bits" in this draft.)

The draft says that the high-order 64 ("p+i") bits of the IPv6 
destination address field are "left untouched".  But it proposes using 
the high-order 56 ("p") bits to hold a special prefix meaning "BIER", 
and it proposes using the next 8 ("i") bits to represent the SI.  That 
doesn't seem like leaving the high-order bits untouched. But perhaps 
"untouched" means "the bits are not modified by the forwarding plane" 
rather than "the functionality of the bits is not modified".

It is worth emphasizing that, unlike other proposed encapsulations, this 
encapsulation only supports BitStrings of length 64.  Well, 128-p-i.  I 
guess one could use a /40 prefix and a single SI to get a 
BitStringLength of 88 if one doesn't need any more than 88 BFR-ids in 
the domain.  It still seems rather restrictive when compared to the 
other encapsulations that have been proposed.

I don't see how the sub-domain is identified in this encapsulation.

The draft says: "It makes use of a typical IP longest match in order to 
decide whether a packet is a BIER packet or not, which means hardware 
and software existing solutions may be used for that purpose."  But 
existing/deployed hardware and software solutions cannot do the BIER 
forwarding!  So I don't see what advantage is being claimed here.  Or is 
this just a way of saying "at least we don't use IPv6 extension headers" ;-)

The draft seems to suggest that if the payload is an IPv6 packet, one 
can use BIER to multicast it without encapsulating the payload at all.  
Rather, all one has to do is overwrite the enduser's destination address 
with an "address" value that contains the BIER prefix, SI, and 64-bit 
BitString.  Do I understand that correctly? If so, this seems to create 
a number of issues that are not discussed.

Suppose, for example, that the original payload has an IPv6 multicast 
address in its destination address field.  If that is overwritten, then 
when the packet reaches a BFER, the BFER will have no way of knowing 
what the original destination address was.  But the multicast flow layer 
needs that information in order to further process the packet!

If an enduser's UDP packet is carried as the payload of an IPv6 BIER 
packet, and the UDP packet has non-zero checksum, then, as the draft 
says, "the UDP checksum must be recomputed when the BIER bits are 
changed."  So the BIER forwarding plane now has a new function -- it has 
to look to see what the payload is, and whether the the payload has a 
checksum that needs to be adjusted.  Does that sound like a good idea?

The draft says: "It is possible to configure a host with an address 
which corresponds to a BIER address with a single bit set.  From the 
host perspective, such address is not different from a regular IPv6 
address."  Well, what will then stop the host from using that address as 
an IPv6 source address?

Packets carrying such an IPv6 source address may get dropped for using a 
prefix that has not been delegated to the host's subnet.

If a host uses a "BIER address" as its source address in a given packet, 
and the packet doesn't get dropped, the packet may elicit responses that 
put the BIER address in their destination address fields.  This seems 
like a security issue, as it creates an attack vector that can create 64 
responses to a single probe.

Hopefully hosts will not treat the BIER prefix as a delegated prefix 
that they can use to compute their own "privacy addresses"; if any of 
those computed addresses make it to the source address field of an IPv6 
packet, and the packet does not get dropped, chaos could ensue.

The draft suggests that the BIER prefix can be treated by BFRs outside a 
given domain as a routable unicast prefix, presumably leading towards 
one or more BFRs that serve as border routers for a given BIER domain.  
(At one point, the draft even says that BIER packets are IPv6 unicast 
packets, which seems a bit misleading. ;-)) That's interesting, but 
putting this feature to use requires one to work out quite a few details 
that are not mentioned.  And I don't think it will work for non-BFRs 
within the BIER domain.  To pass BIER packet through non-BFRs within the 
destination BIER domain, one still needs additional encapsulation.

The draft talks about "configuring" a BIER router with the rules needed 
to interpret a given IPv6 destination address field.  Does this mean 
that IGP/BGP extensions for signaling BFR-ids and other BFR parameters 
will not be used?  Why?  Or is it allowable for these parameters to be 
signaled as well as configured?  And if we are going to talk about 
inter-domain BIER, how is the inter-domain signaling done?

It is not clear from the draft whether the value of i (number of bits in 
the SI field) and the set of BFR-ids is specific to a given prefix, or 
whether it is the same for all prefixes.  (Or for all prefixes 
corresponding to a given domain.  Or perhaps sub-domain?)

Section 6 gives the "advantages" of the proposal, but it is not clear 
what the proposal is being compared to.  For instance, one of the 
advantages is claimed to be that the proposal doesn't use IPv6 extension 
headers.  Is the proposal being compared to another proposal that does 
use IPv6 extension headers?  If so, where is that proposal described?  
(None of the proposals I've seen so far use IPv6 extension headers.)

Another "advantage" is that the proposal "may be used for transporting 
IP multicast packets, but also for sending IP payloads directly to 
multiple destinations".  Does this "advantage" distinguish it from some 
other proposal?  I'd have thought that any multicast encapsulation can 
cause any packet to sent to multiple destinations.

Of course, maybe the first question is whether we really have a need for 
an encapsulation that is IPv6-specific.  The draft doesn't actually seem 
to address this question.