Subject: [lisp] Design discussion -06-(1) -> DF=1

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Dec 2009 18:35:37 -0800

A description of the design issue:

(1) Use stronger language to have the outer IPv4 header set DF=1 so we
     can avoid fragment reassembly in an ETR or PETR.  This will also
     make IPv4 and IPv6 encapsulation have consistent behavior.

Right now the spec does not recommend a preference on the DF setting  
of an outer IPv4 header. If a LISP encapsulator (a ITR or PITR/PTR)  
sets DF=0 an intermediate router could fragment the packet to the  
tunnel destination endpoint. That would be a ETR or PETR. We don't  
want to force ETRs and PETRs to reassemble packets if we can be  
practical. We want Path MTU discovery to be used on the path.

Do people have objections to recommending this?

Thanks,
Dino/Darrel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 22 Dec 2009 08:24:06 -0800

Dino,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
> Sent: Monday, December 21, 2009 6:36 PM
> To: [email-masked]
> Subject: [lisp] Design discussion -06-(1) -> DF=1
> 

The two dangers of doing this are that the ITR might not
receive legitimate ICMP "Packet Too Big" (PTB) messages,
and that it might receive spoofed PTBs. The ITR could
simply ignore all PTBs, but then there is danger of a
path MTU black-hole.

Fred
[email-masked]

> Thanks,
> Dino/Darrel
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Dec 2009 16:52:02 -0800

> simply ignore all PTBs, but then there is danger of a

You are right. So the wording has to be careful. How about something  
like this:

    When the outer header encapsulation uses an IPv4 header, it is
    recommended the DF bit be set to 1.

That doesn't imply MUST but encourages using PMTU-discovery. But if  
the encapsulator can keep the post encapsulated packet under 1500 and  
just do PMTU-discovery between itself and the source in its site, then  
the chances of fragmentation between the ITR and ETR are reduced.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Dec 2009 07:31:21 -0800

Dino,

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Tuesday, December 22, 2009 4:52 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [lisp] Design discussion -06-(1) -> DF=1
> 
> > Dino,
> >

I don't see how any DF=1 approach can address the
concerns no matter how careful the wording.

> the chances of fragmentation between the ITR and ETR are reduced.

Limiting packet sizes to 1500-ENCAPS may be undesirable
since original sources will experience excessive path
MTU discovery interactions that they have never had to
deal with before. Also, there is no provision for moving
up to larger MTUs in the future without running the risk
of hitting an MTU speed bump.

There is a way to solve all of this.

Fred

---

From: Jesper Skriver <[email-masked]>
Date: Mon, 28 Dec 2009 10:42:05 +0200

Fred,

> simply ignore all PTBs, but then there is danger of a

True, but the same is true for any other traffic sent with DF=1, which is a significant part of all traffic today. Also practical experience with deployment of IPsec based VPNs shows that path mtu discovery works well in practice.

Indicating in the spec that path MTU discovery should be used, will ensure that it will be a rare event that an ETR or P-ETR will have to do reassembly prior to decap. Yet at the same time allow an ITR, which has problems receiving ICMP packet too big messages, to disable path MTU discovery for packets generated by it.

As it is the ITR which both controls if it sets DF=1 and it is the ITR which can have problems receiving ICMP packet too big messages, the control for solving any problem seen lies with the one that experience the problem, and thus we do not have a case where someone experiencing problems need to coordinate with a large number of other parties.

On the other hand, if we encourage packets to be sent with DF=0, and an ETR is connected via a lower MTU link that the typical ITR, then packets destined to that ETR with DF=0 will be typically be fragmented in the network before reaching the ETR. Forcing the ETR to do reassembly, without any way of preventing it, short of contacting the admin of any ITR which will be sending it traffic - something which clearly is not practical.

/Jesper

> [email-masked]

/Jesper