Hi Tony,
Before I respond to your reply, I want to ask again some questions
from my first message:
When an application does a DNS lookup of an FQDN via the ILNP stack,
and the stack receives the results and finds ID and L64 records (I am
ignoring ILNPv4, LP records etc. for simplicity) does the stack
return the IP address to the application with the upper 64 bits zeroed?
How does the ILNP stack in B find out about all of A's Locators? I
asked:
Ran - do both A's ILNP stack and B's ILNP stack also send ICMP
packets to each other, secured by the nonce the received from the
other, to tell each other their full set of Locators? I
understand each host's ILNP stack does this if its Locator
changes. A's ILNP stack doesn't need this, since it just looked
up B's Identifier and Locators from B's FQDN. However, B's ILNP
stack has no idea what A's other Locator(s) if any, are. Is the
ICMP message meant to be used at session initiation, like this -
or is it only to be used if a host changes its Locators?
You wrote:
> Your assumption and definition of "won't work" with ILNP is
> incorrect.
>
> An application that specifies an address (and not a FQDN) can
> perform initial packet exchanges while the stack does a reverse
> name lookup followed by a forward lookup.
Is this mentioned in the ILNP I-Ds?
Referring to my example, let's say B is running a web server and A a
web client. In my original example, the web client started the
session with B's FQDN. Here I will explore your explanation of A's
application starting with an IP address for B.
So this could be an example of a referral from D. Let's say an
application in D knew B's IP address GGGG-BBBB. D has no ILNP stack,
and the application in D must be able to work in an ordinary IPv6
fashion with the server in D, though I haven't yet figured out all
the details. Somehow, an application in D communicates this
information to the web client application in A.
Alternatively, the server in D gives its own IPv6 address to A via
some direct or circuitous means, or there is a URL in some web-page
which does the same thing. (e.g. Google cache results using numeric
IP address URLs - and D is the server for those cached results.)
So the application in A opens a socket ready to start a TCP session
with B's port 80, via B's IP address:
GGGG-BBBB
The ILNP stack doesn't know whether the host at the above address has
an ILNP stack or not. The ILNP stack sends the initial SYN packet to
this address, with a source address of:
EEEE-AAAA
because I have assumed that this is the address A uses for IPv6
purposes - one of the two it has from its two ISPs, the other being
FFFF-AAAA.
The ILNP stack recognises this as an initial packet, and I assume it
attaches an ILNP nonce to it.
But how does A's ILNP stack know to do this? If it doesn't attach an
nonce, B will never know that A is an ILNP host. Then, the
communication session will be stuck in IPv6 mode - meaning that ILNP
doesn't provide any benefits for a session which begins with an IP
address - that ILNP only works for sessions which begin with a DNS
lookup of an FQDN.
Page 7 of draft-rja-ilnp-nonce-03 has the relevant material:
If the initiator supports the I/L Split mode and from DNS data
learns that the responder also supports the I/L Split mode, then
the initiator MUST generate an unpredictable nonce value, MUST
store that value in a local session cache, and MUST include the
Nonce Destination Option in its initial packet(s) to the
responder.
But how is the ILNP stack in A to know it should send a nonce with
this packet?
It can't very well delay the packet, do a reverse lookup on B's IP
address, find B's FQDN, do a lookup on that and if the reply
contains ID and L64 records, then send the packet with a nonce.
Yet if the ILNP stack in A sends a nonce with every initial packet to
an IP address which doesn't match anything in its cache, then doesn't
this add to the length of every initial packet? Theoretically,
the routing system and destination IPv6 hosts should not be affected
by the nonce destination option, but it is an extra burden on the
packet and reduces its maximum payload.
Also, in a plain UDP protocol, initiated from a FQDN with DNS lookup,
to an ILNP destination host, assuming the stack somehow does correctly
discern each "initial packet" to a given destination and attach a
nonce to it, what happens if the initial packet is dropped but that a
second or subsequent packet (without a nonce) was received?
The destination host's ILNP stack would never see the nonce, and would
have to assume the initiating host was not an ILNP host. I think this
would make support for ILNP multihoming, mobility and TE quite
unreliable with UDP protocols. At least with TCP, the stack has a
good chance of identifying an "initial" packet, and attaching a
different nonce to subsequent SYN packets to the same destination, on
the reasonable assumption that one of these subsequent packets might
be the first to be received.
Back to the example:
The ILNP stack in B recognises the nonce, establishes the appropriate
session state and stashes it there.
But what information does the ILNP stack in B give its TCP layer about
the packet from A? As far as I can understand, from reading all the
ILNP I-Ds, the ILNP stack recognises that A is an ILNP host, and would
therefore zero the upper 64 bits of the source address of the packet to
0000-AAAA
before passing it to the TCP layer. Is this correct?
I will assume this happens. Next the TCP layer sends back a SYN-ACK
- with its specification of the destination address being 0000-AAAA.
The ILNP stack will send out the packet with a destination address of:
EEEE-AAAA
since at present, EEEE is the only Locator the stack knows for the
Identifier AAAA. (Actually, B has no way of knowing yet whether EEEE
really is a valid Locator for AAAA, but that is for a later discussion.)
The ILNP stack in B could send this SYN-ACK packet via either of its
two ISP links. Here I will assume it uses the link which has the GGGG
/64. The ILNP stack in B also attaches an ILNP nonce to this packet.
So the packet is:
Destination EEEE-AAAA
Source GGGG-BBBB
With nonce
SYN-ACK
A's stack receives this, passes it to the TCP layer as:
Source 0000-BBBB
Is this correct? In my previous message I quoted two passages from
the I-Ds which made me think the ILNP stack, for ILNP sessions,
always zeroes the upper 64 bits when passing the packet to the
transport layer - TCP in this case.
But the transport layer - and/or the application above it - won't
accept the SYN-ACK packet in this form, since the source address does
not match the destination address with which it send the SYN:
EEEE-AAAA.
Please clarify how the ILNP stacks behave to this point, and I will
continue the example in a future message.
- Robin
> Note that this can be done in parallel with the initial exchange,
> so this introduces no latency. Further, the results can be locally
> cached.
>
> Finally, if the lookups do not succeed, the application is still
> effectively a legacy v6 application. Since data is being
> transferred by the transport as requested, this constitutes
> 'working'.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
