RE: IETF 57 Multu6 WG - Monday morning session - minutes

["marcelo bagnulo" <marcelo@it.uc3m.es>]

I would like to extend a bit the answer to Pekka N. (it is not that i will
tell anything new to Pekka, but perhaps this will clarify to others)

In order to preserve established communications more than 7 minutes using
MIPv6 you need to change the CN.
However, perhaps (and a very big perhaps) the changes proposed in
draft-bagnulo-mobileip-unreachable-hoa-00 can be adopted in MIPv6 because
other reasons that multi-homing, since the proposed change also protects
mipv6 communications when the HA is no longer reachable (actually, this was
Pekka N. idea)

Regards, marcelo


> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Christian Huitema
> Enviado el: martes, 15 de julio de 2003 10:40
> Para: Geoff Huston; Kurt Erik Lindqvist; multi6@ops.ietf.org
> CC: proceedings@ietf.org
> Asunto: RE: IETF 57 Multu6 WG - Monday morning session - minutes
>
>
> Geoff,
>
> Thanks for the notes. You made a slight typo in the reporting of
> my talk, when you wrote "We appear to
> be able to design solutions that require changes to the IPv6 standards, do
> no require address rewriting at exit points, but it could work".
> What I said was, "We appear to
> be able to design solutions that ^do not* require changes to the
> IPv6 standards, do
> not require address rewriting at exit points, and could work."
>
> There is also a small typo in a response to Pekka. You wrote:
>
> PN: You need to change the address in both ends.
> CH: The time appears to be around 5 or 6 minutes.
>
>
> The actual question was "you need to change code at both ends"
> (as Marcello explained, you need to do something to some MIPv6
> timers to be more efficient). The response was, "You don't need
> to change code if you are satisfied with the default timers,
> which appears to be around 5 or 6 minutes."
>
> -- Christian Huitema
>
>
>
>
> ________________________________
>
> From: owner-multi6@ops.ietf.org on behalf of Geoff Huston
> Sent: Mon 7/14/2003 10:02 AM
> To: Kurt Erik Lindqvist; multi6@ops.ietf.org
> Cc: proceedings@ietf.org
> Subject: IETF 57 Multu6 WG - Monday morning session - minutes
>
>
>
> Multi 6 Monday 1300 - 1500
>
> Agenda - overview of submitted drafts
>
> Agenda bashing: none
>
>
> - - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min
>
>
>          For background:
>          draft-moskowitz-hip-arch-03.txt
>          draft-moskowitz-hip-07.txt
>
>    Host Identity Protocol (HIP) has been around for some time. New
> namespace protocol with a history of around 4 years. Today sockets are
> bound to IP addresses, forcing the IP address into a dual role of endpoint
> identifiers and forwarding identifiers. HIP introduces a new namespace
> between the network and transport layers. The sockets are bound to host
> identifiers that are dynamically bound to IP addresses. Hosts are
> identified with public keys, not IP addresses, and apps see only the HIP
> identifiers. The apps need not change is the assertion. Hosts can easily
> have both IPv4 and IPv6 addresses, and the assertion is that end-host
> multi-homing and mobility is trivial. HIP Proxies are described as a kind
> of a hack. HIP may be a part of the multi-homing architecture. 4
> Interoperating implementations, intend to send the drafts to the IESG, and
> more work is needed on mobility and multi-homings with NAT traversal. HIP
> is not a working group but is progressing in the background. HIP is a
> multi-address solution with end-to-end. It solves only one aspect of
> multi6, and has no specific solns for address selection or TE
>
> Matsataka Ohta: You said "HIP Proxy" - do you support
> multi-proxies for backup
> Pekka Nikkander: There is no easy way to have multi HIP proxies in some
> situations, and it does represent a single point of failure
>
>
>
> - - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min
>
>
>    SCTP approach - endpoints have multiple addresses, where each
> IP address
> represents a path to a particular endpoint. SCTP is not aware of the level
> of path distinguishing - it would be good if they were, but this is not a
> known property. SCTP can detect path up/down. (Example of
> host-to-host with
> 2 addrs on each host). Multi-homing open up new horizons for SCTP: add and
> remove ip addresses dynamically to the endpoint, that can support
> mobility.
> Functionality at the endpoint is asserted to be superior to network
> functions in this regards. It does imply that the host requires a routing
> table - not a big deal for a host is the claim. But a big table
> is required
> for a system with a large connection load. How to maintain the routing
> table is claimed to be implementation dependant (pre-configured or caching
> the INIT). NATs are in the draft because they wanted to warn everyone how
> bad NATs really are! NAT cases for SCTP generates problems that do no
> appear to have straightforward solutions. From the transport level SCTP is
> claimed to be a 'should work' solution.
>
> Lixia Zhang: How about UDP?
> Lode Coene: its the same problem, with the application having to undertake
> the selection.
> Erik Nordmark: what algorithms have been used in SCTP work to
> select source
> and destinations? Any write ups of this work?
> Lode Coene: none known to me.
>
>
>
> - - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min
>
>    Proposes to use MIPv6 to the multi-homing (mh) problem. Example in
> presentation of recovery from current to backup path (Using alternate
> addresses) Both paths have to be bound and identified _before_ an outage
> using binding update messages. The alternate binding will use the Home
> Address Option. Since MIP already needs the exchange of messages
> along each
> path, this exchange can be used as a path keepalive. The lifetime of the
> binding is limited to 7 minutes, and this is considered to be very short.
> Possible solutions are proposed
>
> Matsataka Ohta: IPv6 has large timeouts for various purposes. If your
> proposal to have the same property so that the new address can be
> used quickly.
> Marcelo Bagnulo: this issue is to build a path outage detection,
> and we are
> proposed to use the packet exchange for this purpose. The idea is to use
> the same packet format, but change the timing.
>
>
> - - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min
>
>    General introduction on IP and IPv6. References 8+8 Locator
> and endpoint
> I-D. The proposal is to let end systems have multiple addresses. Let the
> other end select the 'best' address. (The host addresses are part of
> multiple upstream aggregates). The general architecture proposed is to let
> the network inform the host about state to allow the hosts to undertake
> address selection. When should a host attempt alternate
> addresses? Proposed
> in response to ICMP, routing change, timeouts (TCP only). Proposed that
> applications have an IP (and UDP)-defined packet timeout to trigger
> alternate address use. For very short timeouts it is proposed to send
> multi-copies of the packet with multiple addresses. e-2-e mh and IP
> mobility are similar, although there is mobility timing at the IP layer.
> e2emh has been implemented and running on NetBSD with LIN6, with
> modifications to the stack as described in the presentation. The design
> framework proposed is to make everything optional. Exercising no
> options is
> single-homed. Use 8+8 Locator/Id separation, with packet reception and
> connection identification determined by the ID. Application to mobility is
> also described. Multiple addresses are supplied to the peer by reverse
> query of DNS using an ID query key followed by a forward query,
> or carry in
> the TCP header or a new DNS query type. e2e approach is proposed as
> scaleable architecture. MH and mobility are related, and the approach uses
> 8+8 separation
>
> Pekka Nikkander: You did not mention security issues in your
> presentation -
> is this to be addressed later on, or do you have comments now?
> Matasaka Ohta: The current Internet is weakly secure.
> Cookie-based security
> for locator change give only the same level of security.
>
> Peter Werny: What is required in the DNS for this to work?
> Matasaka Ohta:  this is different from current V6, as it only uses the
> identifier 8 bytes. In DNS we look up locators of location agents using ID
> of hosts.
> Peter Werny: Every host has to have a DNS entry?
> Matasaka Ohta:If there is no DNS and not TCP then you are
> single-homed, and
> you cannot use this mechanisms.
> PW: Your draft has no mention of DNS update
> Matasaka Ohta: Location is not in the DNS - just the location agent.
> Erik Nordmark: Are you assuming a structure for the identifiers?
> Matasaka Ohta: It should be reverse lookup-able. Its better to have
> hierarchy in the identifier space, but you can do without hierarchy if you
> use TCP instead of the DNS to pass the multiple addresses
>
>
>
> - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min
>
>    Each end application can determine a route to use.
> Applications select a
> route using a selection of a specific source and destination address pair.
> An end application can select a path without full route information is the
> claim. The attributes are claimed to include redundancy and load
> balancing.
> Modifications to hosts, routers and routing protocols is needed. Site exit
> router selection using source address routing enables redundancy, load
> sharing with multiple paths. Some mechanisms is needed for 'proper' source
> address selection. Transport layer survivability could be an SCTP
> mechanism
> or other.
>
>
>
> - - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min
>
>    Socket API extensions. Propose to use application layer,
> rather than the
> network. Uses 8+8 model. The API is for manipulation of multiple addresses
> in the application. LIN6 is based on the 8+8 model. LIN6 does address
> acquisition, notification, registration in a secure manner. Hosts identify
> their peer and themselves using only the identifier part. e2e-mh
> is seen to
> be an application of the LIN6 model. The trigger to switch
> locators is seen
> to be ICMP-based using host unreachable. APIs need to manipulate locators,
> to make a multi-locator-ready socket, allow API to change locators on the
> fly, and acquire remote locators. The details of API changes described, in
> socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended
> for active mh applications. UDP requires application support. Future work
> is to put support in to the TCP level, so that no changes are required for
> API for TCP.
>
>
> - - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min
>
>    All hosts should have full default-free routing table. This allows
> selector in host to make optimal locator choice, and know when locator is
> unreachable. source address selection for ingress filtering only. The peer
> will not use the source address - it will make its own selection of a
> locator for the peer. Extended example of policy control and filtering.
>
>
> Pekka Savola: Both of these drafts have been obsoleted
> Matasaka Ohta: not a problem!
> ? (MCI): IF an NLA gets address space from 2 TLAs which does it use?
> MO: If gets 2 addresses, as does its customers. The number of prefixes
> cascades down.
> ? MCI): Scaleaility?
> MO: yes, and NLA should be no more than triply homed.
> Iljitsch van Beijnum: Why is the information in the routing table superior
> to information you can obtain from the other end?
> MO: This does not have scaleability problems if you limit connectivity.
> This is a connectionless system where a host has no information about the
> other end, and the routing table is local information you can use.
> Iljitsch van Beijnum: ok, but I disagree with this
>
>
>
> - - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min
>
>
>    Solution for traffic engineering for mh need sites in a multi-address
> environment. Each host has 1 address per upstream provider. Noted that
> choosing a source address implies choosing a provider (assuming providers
> perform source address filtering). Which source? A host has no information
> about which provider to use to reach a destination. Propose to use a
> dedicated agent (server). A host will query the server with a destination
> address, and the server responds with the source to use. The burden of
> selecting the source address is aggregated to a dedicated server. Note it
> gives only a hint to the host about what address to use. NAROS is not
> intended to preserve flows across address changes. SCTP or HIP could be
> used to preserve flows. The server could be anycast, or undertaken without
> provider interaction. The host / server protocol is a query
> response packet
> exchange. Where multiple choices exist, multiple parameters can be used to
> make the selection.
>
> Pekka Nikkander: is this a new protocol, or, perhaps, ICMP
> Cedric de Launois: No particular protocol - it could be ICMP
> PN: There are security issues here, like secure neighbor discovery
> Michael Richardson: Takes the example and adds further connections, and
> then adds a policy question about 'acceptable traffic' policies. Can NAROS
> deal with this>
> CdL: A lot of requirements could be placed in the NAROS server
> and it could
> be aware of those kind of requirements.
> Matsataka Ohta: Anycast does not include increased robustness for server
> failure. A NAROS server crash will not bring down a anycast
> route. Also 300
> seconds is too large a value.
>
>
>
> - - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David
>     Kessens, 20 min
>
>    Simple multihoming experiment. A problem statement in a bounded example
> environment. A simple network is a single link where multiple hosts see
> multiple boundary routers where each router is connected to distinct
> upstreams. Addresses from providers are mapped to all the hosts. Asserted
> that this is not uncommon in V4 and that the common solution is to NAT the
> local net and allow the NAT to 'rehome' to each outbound. The consequence
> is flow breakage across the rehoming of the NAT. The bounds are that the
> ISPS do not exchange information, there are provider addresses with an
> assigned prefix per provider. Hosts configure an address with each prefix.
> Need to resolve host choice of egress router selection (as a function of
> the source address)
>
> Erik Nordmark:  There are people talking about movement
> detection, and this
> gets all routers to advertise all prefixes
> Christian Huitema: Thats not incompatible - several routers can advertise
> the same information, provided that the information is equivalent, and the
> routers can handle all such packets.
> Pekka Savola: please clarify the applicability. This is only the
> case where
> hosts are directly connected to all egress routers.
> Christian: this is a common case.
> MO: You don't need tunnels in a single link network. In a multi-link
> network you need tunnels.
> CH: This does nothing for MTU discovery. For single link there is a very
> simple solution and this can be extended for multi-links
> MO: Ands I'm saying its impossible
> CH: fine!
>
>    No need for tunnels in a single link network, and the routers can pass
> off to each other in the event of dynamic failure. The assertion
> is that in
> a single link network this requirement can be easily met. Dead exist
> routers or dead ISP require some consideration. If the exit router knows
> that the path is dead it can send a poison advertisement of the
> prefix. The
> real issue with this form of mh is a very soft definition of
> 'broken' where
> the link may be up, but the path to the remote end point may be unuseable.
> This kind of problem is an e2e detection issue. Hosts may need to keep
> track of connections and track quality. If you know an ingress
> path is dead
> do you need to update the DNS to remove the dead prefix from your host
> entry? Of course you may not know and in this case your peer will need to
> work out what address to use. Maintenance of TCP connections is an issue.
> MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he
> connection will fail, and needs to be reestablished. Exit / entrance
> selection is also an issue. One approach is to only advertise the
> preferred
> address in the DNS if you have a primary / backup scenario. And in a 1 + 1
> scenario, then advertise both. On the outgoing the solution may be a local
> server to assist, or to document preferences in the routers. We appear to
> be able to design solutions that require changes to the IPv6 standards, do
> no require address rewriting at exit points, but it could work,
>
> Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need
> to change both ends?
> CH: The support for the connected node in MIPv6 is supposed to be
> implemented everywhere.
> PN: You need to change the address in both ends.
> CH: The time appears to be around 5 or 6 minutes.
> PN: If you are going to change the code at both ends then you should try
> HIP in your experiments as well.
> CH: You are free to experiment with HIP
> Fujikawa: It seems like an application cannot select different path from
> other applications in a host?
> CH: No, not so. The host has several IPv6 addresses. An application that
> want to do path selection can bind to a source address and connect to a
> destination and select a path.
> Matasaka Ohta: It is stupid to keep using a complication MIPv6
> CH: Complexity is management of the Home agent and security functions to
> certain classes of attacks and you will need  to have some form
> of security
> in any case.
> Matasaka Ohta: This only works in a single link case.
>
>    In a larger site the problem is ingress filtering, because its
> harder to
> do source-based routing. The simple solution is to work with the ISP to
> lift source filters. Even larger sites have their own PI space and AS#.
>
> IvB: Disable ingress filtering can be down for the local upstream, but the
> chain may extend upward
> CH: ingress filtering in the middle of the Internet is a bad idea
> MO: what will you do with a large site?
> CH: lets call them medium
> Bob Hinden: ISPs would be more amenable to break ingress filtering than
> route specifics.
> ?: Ingress filtering should not be an issues.
> Mat Ford: Define a large site?
> CH: establish a registry relationship!
>
>
> - - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min
>
>
>    Claimed that this is not the best solution in all cases, but
> better than
> some others. Need to avoid the routing mess of advertising more specific
> and need solutions soon. Approach to use the AS number to create PI space
> for larger enterprises. e.g. 2000:<ASN>::/32. Issues about 16 / 32 bit AS
> numbers, and a claim that 32 bit AS numbers would indicate a RIR policy
> failure.
>
>
>
> Moshens VC(?): How do you get uniqueness of the prefix
> PS: This is 2000 - it won't collide!
> MO: There are already too many ASes deployed
> Geoff Huston: You are assuming AS remain at 16bits. What happens when AS
> drain in 2011. and we move to 32 bit AS numbers? This is a
> relatively short
> term solution with a visible drop dead point - right?
> PV: yes.
> ?: This is good solution
> PV: an appendix shows how to deal with 32 bit AS numbers, but I
> don't lkike
> this solution.
> Tim Chen: This cuts out the smaller sites that do not have ASs.
> Randy Bush: Why reluctant to give out ASes to routing domains who's policy
> domains are different from their neighbors?
>
>
> - - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum,
>     15 min
>
>
>    Geographical aggregation. Admitted that topology is not correlated to
> geography, and even if the geo part doesn't work there are still
> some savings.
>
> MH: This gives little actual aggregation
> ?: Asymmetrical routes break in your model
> IvB: Routing is asymmetrical in multi-homing in any case.
> Tony Hain: Aggregatibility is the question. The concept appears fine, but
> you are making assumptions about aggregation boundaries here.
>
>
>
>
>
>
>