slight comments on shim6 proxies (1)

Deguang Le <le@cs.uni-goettingen.de> Thu, 01 March 2007 13:01 UTC

Envelope-to: shim6-data@psg.com
Delivery-date: Thu, 01 Mar 2007 13:03:19 +0000
Message-ID: <45E6CEAF.6020307@cs.uni-goettingen.de>
Date: Thu, 01 Mar 2007 14:01:35 +0100
From: Deguang Le <le@cs.uni-goettingen.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7.12) Gecko/20050915
MIME-Version: 1.0
To: shim6@psg.com
Subject: slight comments on shim6 proxies (1)
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit

Hi Marcelo, all,
I read through the insightful draft and I have some questions and 
comments on Section 3 as follows:

To my understanding, the proposed approach employs two kinds of IP 
addressing: the PI addressing and CMULA addressing, then the PI is used 
as the locator and CMULA is used as the ULID separately. Right?
If it is right, I wonder why we need to use a special IP addressing 
(i.e. the CMULA) as the ULID.
Doesn't the base shim6 protocol (draft-ietf-shim6-proto-07.txt) 
specifies to use the locator as the Upper Layer Identifier (ULID)?

I am confused by the following sentence:
*Hosts within the multihomed site are IPv6 hosts without any shim6 
support and they are configured only with a single address containing 
the CMULA prefix.*
Since the non-shim6 capable hosts are only assigned with a single 
address containing the CMULA prefix, is it feasible to put these 
non-shim6 capable hosts in any place of the Internet and not necessary 
to put them in a multihomed site? We only need to put the P-SHIM6 in a 
multihomed site. Right?

It is not clear for me how the new *ULID RR* is specified in the 
existing DNS.

I am not sure whether the CMULA is stored in the "ULID RR" or "AAAA RR" 
on earth, because the following contexts presented in section 3 seem not 
consistent:
PA addresses are published in AAAA RR while *CMULAs are published in a 
new ULID RR*.
The reply is processed by the DNS ALG of the multihomed site and only 
*the CMULA is returned to H1 in a AAAA RR*.

The following statement is not clear to me:
*When H1 sends the first packet addressed to the CMULA of H2, the packet 
is intercepted and processed by the P- Shim6 box of the multihomed site.  *
How could the P-SHIM6 intercept the first packet addressed to the CMULA 
of H2?
Does the H1 send the first packet to the CMULA of H2 directly using the 
common IP routing or does the H1 need to send the first packet to the 
P-SHIM6 at first?

Section 3 provides an example to explain how the proposed approach would 
work. However, it is not clear for me how a ULP connection (e.g. a TCP 
connection) could be established between the H1 and H2 through a 
P-SHIM6. I think it is important to describe how ULP connection is 
established and preserved through the P-SHIM6. :-)

Cheers,
Deguang

marcelo bagnulo braun schrieb:

> 
> Hi,
> 
> i have included in this draft some level of detail on how to do proxies 
> in shim6, in order to support unmodified hosts, allow some middle boxes 
> to perform egress path selection and provide PI identifiers, so that we 
> can have an idea of how this would look like in the shim approach
> 
> Comments are welcome
> 
> Regards, marcelo
> 
> Inicio mensaje reenviado:
> 
>> De: Internet-Drafts@ietf.org
>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>> Para: i-d-announce@ietf.org
>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>> Responder a: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : Proxy Shim6 (P-Shim6)
>>     Author(s)    : M. Bagnulo
>>     Filename    : draft-bagnulo-pshim6-00.txt
>>     Pages        : 22
>>     Date        : 2007-2-27
>>     
>>    This draft discusses extensions to the shim6 architecture to support
>>    shim6 proxies that would allow the provision of the following
>>    capabilities:
>>    o  Provide Upper Layer Identifier portability.
>>    o  Provide Traffic Engineering policy enforcement.
>>    o  Off-load of the shim6 context management from the actual peers of
>>       the communication.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-bagnulo-pshim6-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     mailserv@ietf.org.
>> In the body type:
>>     "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <2007-2-27120849.I-D@ietf.org>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
>