Re: [BEHAVE] draft-chen-behave-rsnat-01

[Iljitsch van Beijnum <[e-mail]>]

I have reread the draft.

If I understand correctly, the idea is to use BGP to synchronize state  
between multiple stateful translators, where each translator handles a  
part of the address space used in translation at any time. Many people  
will argue that this deviates too far from BGP's purpose.

I can see that argument, but rather than convince you to not use BGP  
for this, I would like to explain that _if_ you're going to use BGP  
for this, you'll have to think about how to do that.

What you need is for mapping information to be exchanged that consists  
of IPv4 and IPv6 source and destination addresses and ports and the  
protocol. That's 9 items. You can probably optimize a few of them  
away, but using the normal IPv4 address family would require you to  
encode the remaining information in a new path attribute. However,  
this doesn't work: if translator A has a mapping from 2001::2001 to  
192.0.2.1 and translator B from 2002::2002 to 192.0.2.1, then if they  
both announce this to translator C, C would not combine this  
information but rather select either the info from A or from B.

(And you define the attribute as transitive, which means that it would  
be propagated in eBGP, which is unnecessary and has the potential for  
problems when the information leaks.)

What would work better here if you defined a new address family that  
consists of the concatenation of source address, source port,  
destination address, destination port. This could be either IPv4 or  
IPv6. Then the other protocol version addresses and ports plus the  
protocol number would be encoded in a path attribute. This way, each  
mapping would be a separate NLRI in the new AFI and there would be no  
problem merging the information.