Subject: BGMP Identifier

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Feb 2000 15:10:46 -0800 (PST)

The description of "BGMP Identifier" in the OPEN message format states:
> This 4-octet unsigned integer indicates the BGMP Identifier of
> the sender. A given BGMP speaker sets the value of its BGMP
> Identifier to a globally-unique value assigned to that BGMP
> speaker (e.g., an IPv4 address).  The value of the BGMP Identifier
> is determined on startup and is the same for every BGMP session opened.

Actually it turns out that the value need not be globally-unique,
as long as it is unique among peers (i.e. no one peers with two
different speakers that have the same BGMP Identifier).

I'd like to ask for comments on how this should be handed in IPv6.

Option A) Require using a 4-byte unique identifier of the IPv6
          router (not an IPv6 address).  Is it safe to assume that
          all BGMP speakers will have an IPv4 address that meets
          the uniqueness criteria above?

Option B) Change the BGMP Identifier to be 16 bytes long in all cases.
          An IPv4 speaker can pad the first 12 bytes with 0's
          (same technique as an IPv4-compatible v6 address).

Option C) There's a Reserved byte in the header which could be used
          to fill in an AddrFamily number which applies to the 
          BGMP Identifier.  This raises a potential issue in that
          you couldn't use the same BGMP Identifier to talk to
          v6 peers as you do for v4 peers.  This might be okay.

Option D) Make the BGMP Identifier variable length, based on 
          whether the TCP connection is over IPv4 or IPv6.
          Same issue as (C) about having to use different
          local Identifiers for v4 vs v6.

Comments?

-Dave

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Wed, 16 Feb 2000 21:20:46 -0800

>           the uniqueness criteria above?

In the near future probably yes, but after X years the IPv4
addresses may have stock-market value :)

>           (same technique as an IPv4-compatible v6 address).

Is the BGMP ID used for anything else except in the OPEN message to
resolve connection collision? Seems that the answer is "no"
according to the I-D. Then I think that Option B is probably the
easiest and cleanest solution without any negative impact or
overhead.

BTW, according to RFC2373 Section 2.5.4 there are two types of
Embedded IPv4 addresses:
 * IPv4-compatible IPv6 addresses (used to represent the IPv4
addresses of nodes that understand IPv6). Those addresses
have all zeros in front of the IPv4 address.
 * IPv4-mapped IPv6 addresses (used to represent the IPv4 addresses
of nodes that do NOT understand IPv6). Those addresses have FFFF in
front of the IPv4 address, and then 80 zeroes in front.

You may want to use this convention in Option B.

Pavlin

---

From: "Brian Haberman" <[email-masked]>
Date: Thu, 17 Feb 2000 07:26:54 -0500

> addresses may have stock-market value :)

I don't like the idea of forcing an IPv6 node into having to
generate a random 32 bit number for use as an identifier.
I seems clunky.

> front of the IPv4 address, and then 80 zeroes in front.

Would there be a reason to identify whether or not an IPv4 node
knows how to speak IPv6 in BGMP?  It also forces the IPv4
BGMP to know about the IPv6 stack.

> >           v6 peers as you do for v4 peers.  This might be okay.

This approach allows you to use the same transport protocol
independence that is in PIM.  It would allow BGMP to support
other protocols in addition to the IP protocols.

It does increase the processing complexity since you have to parse
the AddFamily field first in order to correctly process the identifier.

> >           local Identifiers for v4 vs v6.

Kind of messy.  What if you wanted to carry IPv6 BGMP
over an IPv4 transport?

Brian

---

From: Brad Cain <[email-masked]>
Date: Thu, 24 Feb 2000 12:04:32 -0500

> I'd like to ask for comments on how this should be handed in IPv6.

FYI

This is from draft-ietf-ospf-ospfv3-stdreport-00.txt

"(1)   OSPF Router IDs, Area IDs and LSA Link State IDs remain at
           the IPv4 size of 32-bits.  This was done in order to keep the
           size of LSAs small.  As a result, OSPF for IPv6 Router IDs
           cannot be assigned as one of the router's IPv6 addresses --
           IPv4 addresses may be assigned to routers implementing OSPF
           for IPv6 solely for the purpose of obtaining OSPF Router
IDs."