[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: slight comments on shim6 proxies (1)



Hi Marcelo,
Thanks you very much for your detailed explaination. :-)
Please see my responses inline, which still have some questions.



 bagnulo braun schrieb:

Hi Deguang,

thanks for the comments

see below..

El 01/03/2007, a las 12:14, Deguang Le escribió:

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?


P-shim uses two types of addresses:
First type: CMULAs which are provider independent as ULIDs
Second type: PA addresses that are used as locators.

So, PA addresses are used as locators, no globally routable PI addresses are used in P-shim in any case

If it is right, I wonder why we need to use a special IP addressing (i.e. the CMULA) as the ULID.


see above

However, I don't understand why the proposed approach has to employ the CMULA as the ULID rather than use one of the locators as the ULID as specified in the base shim6 protocol (draft-ietf-shim6-proto-07.txt)?



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?


this refers to the non shim6 capable hosts inside a multihomed site (or that are served by a P-shim box)

Hosts that are not served by a P-shim6 box cannot be configured with a CMULA because it is not routable

Consider the situation where the non-shim6 capable host accesses to the Internet through a single provider and is configured only with a single globally routable IP address. Then, is the P-SHIM6 box in the proposed approach still able to serve this kind of host?


 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.


becasue we cannot place CMULAs in AAAA records because if we did so, CMULAs would be returned to hosts and hosts (that are not aware of CMULAs and that are not served by a P-shim6) may try to send packets to this CMULA which is non globally routable


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*.


Yes, because a host behind a P-shim, it can use a CMULA as a destiantion address becuase such packet will be intercepted by the P.shim box and the CMULA will be replaced by a gloablly routable PA address

So, the host behind a P-shim box makes a DNS query
The DNS server returns the CMULA in the ULID RR and the routable address in the AAAA RR (this is so becuase the DNS server doesn't know if the host that is asking is behind a P-shim6 or not) The DNS component of the P-shim box processes the DNS reply and presentes the CMULA in a AAAA RR to the host behind the P-shim. the host behind the p-shim sends a packet with the CMULA as dest address, which in turn is intercepted by the P-shim box, which establishes the shim context with the peer and replaces the CMULA address by a valid routable locator

If the destination host (i.e. the peer) does not have the CMULA (e.g. If H2 is a multihomed host as well as is shim6 capable, and all the assigned IP addresses of H2 are PA addresses from its providers), then what does it happen? How does the P-SHIM6 box works or how is the procedure of DNS query peroformed?
Thanks!


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?


because the P-shim must be located in the path between the host that it is serving and the internet

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?


it uses the common ip routing, but the p-shim must be placed on the path between the host it serves and the internet, this can be achieved by configuring the p-shim box to inject a route to the CMULA prefix, so it sinks all the packets with a CMULA as a destiantion address
Because the CMULA of H2, which should belong to the H2's site, is not globally routable, I don't think the first packet with the CMULA of H2 in the destination address field can be routed from the H1 to the S-SHIM6 box in H1's site. :-)
What do you think?



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. :-)


i cannot but agree with this comment, but i am not sure what is that you would like me to detail more...

perhaps with the above clarifications, it is clearer how this works, but let me know if it is not and i can try to make an example...

Does the establishment of SHIM6 context is prior to the establishment of TCP connection?
Thanks!

Cheers,
Deguang



thanks, marcelo



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