Re: Comments on draft-bagnulo-multi6dt-hba-00.txt

Iljitsch van Beijnum wrote:

> I think it's possible to solve this. We've been talking about a bit that 
> indicates (among other things) that rewriting is allowed. For a long 
> time, I've been saying that we could use the prefix in the source 
> address for this. So magic prefix = rewrite, regular prefix = don't 
> rewrite. We can reserve some bits in the magic prefix that indicate the 
> type of rewriting that's allowed. For instance, if the prefix is 
> <iana:32><x:16><subnet:16><iid:64> then we can encode permission to 
> rewrite to one or more of 16 different prefixes. There is the slight 
> problem of having all systems involved know which prefix corresponds to 
> which bit of course, but this should be doable.

Such an approach would require there to be a source locator rewriting 
router in the path, right?
If the above funny prefix isn't rewritten in the path the peer will not 
be able to respond AFAIK.

Since we want to allow incremental deployment of any multi6 technology, 
such an approach would require that the host can find out
  1) whether there is a source locator rewriter out there
  2) whether the source locator rewriter is in the path to reach a
     particular destination (for instance, the path to a destinations
     within the site may or may not go through a rewriter)

If the host needs to probe the network per destination locator to answer 
#2, we might as well have the answer tell the host which is the 
preferred source locator to use so that there is no actual rewriting 
along the path. (Yes, there are some subtle differences should the path 
change.)

The above complexity combined with Geoff's observations that in real 
networks today it is hard to define which is the "site border router" 
which would do the rewriting, makes me personally think that locator 
rewriting along the path might not be worth to complexity even in the 
future.

   Erik