Re: Comments on draft-crocker-mast-proposal-00.txt

[Dave Crocker <dhc@dcrocker.net>]

>> 1. Rendezvous -- finding someone without existing context between the
IvB> I would argue that MAST doesn't perform the initial rendezvous,

that's what I wrote, immediately after the 3-item list.
IvB>  but
IvB> rather just adds additional addresses to an existing context.


>> 3. Multi-address use -- intelligently choosing among multiple available
>> addresses.

IvB> However unless I missed it twice, the MAST draft doesn't really discuss 
IvB> this.

Section 7 of the proposal.



IvB> While we're talking about NATs: how is a host behind NAT going to be 
IvB> successfully multiaddressed?

The PROBE function is explicitly intended to help deal with this question.


IvB> How are you going to decide when an address jump is in order?

That's Section 7, again.


IvB> How does MAST fit in the current communication model? Do you do MAST
IvB> first and then a three way handshake? Set up TCP first and then do MAST?

Was the diagram in Section 4.1 unclear about this?


IvB> Even cooler is letting the routers rewrite the source addresses so:

MAST explicitly seeks to avoid touching infrastructure, most especially
routers.


>> IvB> up additional address space?

>> MAST does not use up new address space in IPv4 or IPv6.  None.

IvB> Except that you need more than one address to get some use out of MAST,

The reference was to "address space", not "addresses".


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>