[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-crocker-mast-proposal-00.txt
>> 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> rather just adds additional addresses to an existing context.
>> 3. Multi-address use -- intelligently choosing among multiple available
IvB> However unless I missed it twice, the MAST draft doesn't really discuss
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
>> 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".
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>