Print

[KiLaHuRtZ]

If anyone is interested...my friend and I have setup somewhat of an "online" lab environment for learning IPv6 and IPv6 with BGP.  We use IPv6 GRE tunnels to connect to each other and form IPv6 BGP peers.  If you would like to join...you can read about it here: http://www.ip6technologies.net/

[kasperd]

This related thread from a few months back may be interesting to you.

[KiLaHuRtZ]

Thanks.  It was a good read, but what we are doing was never intended to be public nor was it intended to provide any fault tolerence or redundancy.  We are simply just exchanging advertisements to play with BGP and IPv6.  We use GRE IPv6 tunnels inside of our IPv6/IPv4 tunnels to HE.  So, regardless, all the traffic goes into and comes out of HE's tunnel server.  The GRE IPv6 tunnels just allow us to create the peers.  It is essentially just a distributed lab environment.

[kasperd]

We use GRE IPv6 tunnels inside of our IPv6/IPv4 tunnels to HE.  So, regardless, all the traffic goes into and comes out of HE's tunnel server.

I would have run the tunnels over IPv4 to avoid cyclic dependencies. There are of course other ways to avoid cyclic dependencies, you just need to be careful.

[KiLaHuRtZ]

Yep, for the GRE tunnels, one must nail up a static route for the tunnel source on the destination end pointing towards the HE tunnel to prevent the GRE tunnel from trying to bring itself up inside itself,... 

[kasperd]

I looked on how you assign addresses to your point-to-point links, and I noticed that your RFC 4193 addresses are not RFC 4193 compliant. There are 40 bits in the address, which must be (pseudo)random numbers. You are putting actual data into those bits.

I can think of a few different approaches you could use to assign link addresses, which would use pseudo-random numbers in that location.

• Use fd7a:5803:9afb::/48 for your point-to-point links. Let the next 16 bit be the XOR of the two peering AS numbers. This will give you a /64 for each pair of AS numbers. They are not globally unique, but they are unique within each AS.
• Use fd10:d942:cb39::/48 followed by two 32 bit AS numbers and a 12 bit link identifier. This will give you only a /124 for each link. But they will be globally unique and support 32 bit AS numbers.
• Generate a psuedo random 64 bit prefix according to the following algorithm: Concatenate a fixed string (for example Bfjm2WnBlM35L9nVBesg8t3VtKs) with the two AS numbers and the link identifier all separated by spaces. Compute a SHA1 of the resulting string. Take fd followed by the first 56 bits of the hash. For example 65535 and 64768 want to peer. On their first link they hash the string "Bfjm2WnBlM35L9nVBesg8t3VtKs 64768 65535 0" and get SHA1 8088f2095dfd457f7b86a91525d24eefdebef34d, thus their link prefix becomes fd80:88f2:095:dfd4::/64.

[KiLaHuRtZ]

I looked on how you assign addresses to your point-to-point links, and I noticed that your RFC 4193 addresses are not RFC 4193 compliant. There are 40 bits in the address, which must be (pseudo)random numbers. You are putting actual data into those bits.

I can think of a few different approaches you could use to assign link addresses, which would use pseudo-random numbers in that location.

• Use fd7a:5803:9afb::/48 for your point-to-point links. Let the next 16 bit be the XOR of the two peering AS numbers. This will give you a /64 for each pair of AS numbers. They are not globally unique, but they are unique within each AS.
• Use fd10:d942:cb39::/48 followed by two 32 bit AS numbers and a 12 bit link identifier. This will give you only a /124 for each link. But they will be globally unique and support 32 bit AS numbers.
• Generate a psuedo random 64 bit prefix according to the following algorithm: Concatenate a fixed string (for example Bfjm2WnBlM35L9nVBesg8t3VtKs) with the two AS numbers and the link identifier all separated by spaces. Compute a SHA1 of the resulting string. Take fd followed by the first 56 bits of the hash. For example 65535 and 64768 want to peer. On their first link they hash the string "Bfjm2WnBlM35L9nVBesg8t3VtKs 64768 65535 0" and get SHA1 8088f2095dfd457f7b86a91525d24eefdebef34d, thus their link prefix becomes fd80:88f2:095:dfd4::/64.

You are correct, however, the randomness isn't really needed in such a small footprint.  The one thing that is needed is the uniqueness.  We chose this way of doing things for a few reasons; 1) Ease of use, 2) This is a lab, 3) Limiting confusion.  In the real world, you are correct, we would randomize there.  One could also use the 64-bit timestamp since epoch and XOR that with something.