Re: slight comments on shim6 proxies (1)

marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 02 March 2007 07:37 UTC

Envelope-to: shim6-data@psg.com
Delivery-date: Fri, 02 Mar 2007 07:37:52 +0000
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Message-Id: <36212d4d1ac76544726e6c57bcafd1d4@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
Cc: shim6@psg.com
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: slight comments on shim6 proxies (1)
Date: Fri, 02 Mar 2007 08:37:17 +0100
To: Deguang Le <le@cs.uni-goettingen.de>

El 01/03/2007, a las 22:25, Deguang Le escribió:

> 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)?
>

you could use a locator of course, but this depends on what features 
you want to obtain
i am assuming that locators will be PA in order to make the routing 
system scale and there we don't want to use routable PI addresses
So if you use a PA addresss as ULID, then you need to renumber when you 
change ISPs and this may lead to provider lock in

So if the site has no problem with that, no problem it can use PA 
addesses as locators as it is in the basic shim6 approach and p-shim 
works

however, if the site wants to achieve provider independence through 
p-shim then it shouldn't configure any provider dependent addressses in 
the host, in order to reduce the renumbering costs in a changing 
provider event

this includes the ULIDs

that is why CMULAs that are provider independetn but that do not 
contaminate the global bgp routing table are used as ULIDs

this has a cost, since in order to support this, additional efferts are 
needed.
I will send an email summarizing all the costs involved in supporting 
this provider independence in p-shim

as i mention above, if the site is not interested in provider 
independence, and only wants p.shim for facilitating deployment or to 
obtain centrally enforced TE, then it can use  p-shim wihtout requiring 
some of the mechanisms


>
>>> 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?
>

yes,
the site will need a p-shim box in the site (or the isp)

even in this case, p-shim can provide a couple of benefits:
- support for multihoming fault tolerance capabilities when 
communicating with a multihomed site that has shim6
- provider independence, since it could use CMULAs in the hosts and the 
renumbering costs would be reduced

>>>  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?

in this case there is no need for the DNS ALG and the reply from the 
DNS is returned untouched to the source host behind the p-shim
one of the PA addresses returned in the DNS query will be used as ULID 
for that context

regards, marcelo

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